Translate

Mostrar mensagens com a etiqueta Ponteiros. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Ponteiros. Mostrar todas as mensagens

sexta-feira, 14 de março de 2025

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

 

Bellacosa Mainframe apresenta passwords e passphrases no racf zos

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

Quando oito caracteres já não conseguem proteger uma galáxia inteira

Por Vagner Bellacosa – Bellacosa Mainframe

"O medo leva ao improviso. O improviso leva ao post-it. O post-it leva ao incidente de segurança."

Introdução – O Jovem Padawan e a Porta do Datacenter

Todo Sysprog Padawan passa por um momento peculiar em sua jornada.

Ele aprende sobre JES2.

Descobre o SDSF.

Sobrevive ao primeiro ABEND.

Começa a entender o funcionamento do RACF.

Admira a elegância dos perfis FACILITY.

Tem pesadelos ocasionais com UACC(READ).

E, inevitavelmente, faz uma pergunta aparentemente inocente:

Mestre Bellacosa, por que ainda existem senhas de oito caracteres em um computador capaz de processar bilhões de transações por dia?

A pergunta é excelente.

E a resposta nos leva para uma viagem que começa na década de 1970 e termina nos sofisticados ambientes Zero Trust do IBM z17.

Este artigo não pretende apenas explicar a diferença entre Passwords e Passphrases no RACF.

Pretende mostrar como a evolução das credenciais acompanha a própria evolução do IBM Z.

Porque segurança em mainframe nunca foi apenas uma questão técnica.

Ela é uma filosofia operacional.

Uma disciplina.

E, em muitos aspectos, uma forma de arte.


O IBM Z nunca foi um computador comum

Muitas pessoas enxergam o mainframe apenas como um computador grande.

O Sysprog sabe que isso está longe da verdade.

O IBM Z é um ecossistema.

Ele é projetado para atender requisitos que poucas plataformas conseguem oferecer simultaneamente.

Disponibilidade próxima de 100%.

Escalabilidade extrema.

Auditoria detalhada.

Criptografia integrada.

Virtualização massiva.

Processamento transacional absurdo.

Em muitos bancos brasileiros, um único complexo IBM Z é responsável por:

PIX;

TED;

DOC;

Cartões;

Previdência;

Empréstimos;

Internet Banking;

Aplicativos móveis;

Open Finance.

Uma falha de autenticação em um ambiente desses não representa apenas um problema técnico.

Representa potencialmente milhões de reais em perdas.

Representa vazamento de informações.

Representa riscos regulatórios.

Representa danos reputacionais.

Por isso RACF existe.


RACF: O Mestre Guardião da Ordem Jedi

RACF significa:

Resource Access Control Facility.

Ele não é apenas um produto.

Ele é praticamente o sistema imunológico do z/OS.

RACF controla:

Usuários;

Grupos;

Datasets;

CICS;

DB2;

TSO;

UNIX System Services;

MQ;

JES;

Operações especiais.

Quando um usuário digita:

LOGON VAGNER

RACF faz inúmeras verificações.

Quem é você?

Você realmente é você?

Sua senha expirou?

Está revogada?

Tentou errar várias vezes?

Está autorizado ao dataset?

É quase como um Jedi verificando um visitante tentando entrar no Templo de Coruscant.


O legado das senhas de oito caracteres

Um jovem profissional pode achar estranho.

Como assim apenas oito caracteres?

A explicação está na história.

RACF surgiu em uma época muito diferente.

Década de 70.

Redes fechadas.

Terminais 3270.

Linhas SNA.

Poucos usuários externos.

Ataques pela Internet?

Praticamente inexistentes.

Botnets?

Não.

GPUs especializadas?

Não.

Malwares ladrões de credenciais?

Não.

Naquele contexto:

ABCD1234

Era aceitável.

Não porque fosse forte.

Mas porque o modelo de ameaças era outro.


O universo mudou

Hoje o cenário é completamente diferente.

Temos:

Credential stuffing.

Ataques automatizados.

Malwares infostealers.

Phishing.

Engenharia social.

Ataques offline.

Data breaches.

Dark web.

Inteligência artificial.

Sistemas expostos por APIs.

Open Banking.

Open Finance.

Cloud híbrida.

VPNs comprometidas.

O atacante atual possui recursos que um hacker dos anos 80 jamais sonharia possuir.


Entropia: o combustível da Força

Um dos conceitos mais importantes em segurança é a entropia.

Podemos simplificar:

Quanto mais possibilidades existem, maior a entropia.

Quanto maior a entropia, mais difícil é descobrir a credencial.

Imagine um cofre.

Primeiro cofre.

100 combinações.

Segundo cofre.

10 bilhões de combinações.

Qual deles você escolheria?

A resposta é óbvia.


O limite matemático das Passwords

Uma senha de oito caracteres possui restrições.

Mesmo utilizando:

Maiúsculas

Minúsculas

Números

Caracteres especiais

Existe um teto.

Por exemplo.

66 opções possíveis.

Elevadas à oitava potência.

66⁸

Aproximadamente.

360 trilhões.

Parece muito.

Mas não é.

Não para hardware especializado.


O grande inimigo chama-se previsibilidade

Padawans adoram criar senhas criativas.

Infelizmente os atacantes também adoram.

Exemplos clássicos:

IBM2026

Cobol65

Mainframe1

Banco123

Bellacosa2026

Parece forte.

Mas é previsível.

Ferramentas modernas usam regras.

Substituições.

Palavras comuns.

Datas.

Nomes próprios.

Centenas de milhões de combinações inteligentes.

Em poucos minutos.


A ascensão das Passphrases

IBM percebeu essa limitação.

E RACF evoluiu.

Surgiu o conceito de Passphrase.

Inicialmente:

14 caracteres mínimos.

Posteriormente.

9 até 100 caracteres.

Uma enorme evolução.


Regras do RACF para Passphrases

O RACF não permite qualquer frase.

Existem salvaguardas.

Não conter o userid.

Possuir duas letras.

Possuir dois caracteres especiais.

Não repetir três caracteres iguais.

Exemplo:

Errado.

VAGNER2026

Errado.

AAAAAAAAAAAA

Errado.

Bellacosa!!!

Correto.

MeuCafeNoMainframe@2026

O crescimento exponencial da segurança

Aqui está o ponto mais fascinante.

Adicionar caracteres produz crescimento exponencial.

Não linear.

Imagine.

8 caracteres.

66⁸

14 caracteres.

66¹⁴

A diferença é quase incompreensível.

É como comparar.

Um copo de água.

Com o Oceano Pacífico.


O ataque de força bruta

Suponhamos.

Um laboratório possui capacidade de testar.

100 bilhões de combinações por segundo.

Uma senha simples.

Pode ser quebrada rapidamente.

Uma passphrase longa.

Poderia levar bilhões de anos.

Na prática.

É impossível.


O paradoxo do ser humano

Até aqui tudo parece resolvido.

Use passphrases.

Fim do artigo.

Não.

Existe um detalhe.

O usuário.

O elo mais imprevisível.


Cenário 1

Senha impossível.

Q7#Xt29L@P

Usuário esquece.

Anota.

Cola no monitor.

Segurança destruída.


Cenário 2

Mesma senha em vinte sistemas.

Vazamento único.

Comprometimento múltiplo.


Cenário 3

Passphrase amigável.

EuTomoCafeNoBellacosa@TodaManha2026

Grande.

Memorável.

Complexa.

Excelente.


O ensinamento do XKCD

Existe uma famosa tirinha.

Ela revolucionou a discussão sobre senhas.

Mostra algo interessante.

Senha.

Tr0ub4dor&3

Difícil lembrar.

Passphrase.

correct horse battery staple

Muito maior.

Muito mais fácil.

Muito mais segura.

A indústria inteira começou a reconsiderar suas práticas.


O NIST mudou de ideia

Antigamente.

As organizações exigiam.

Trocar senha mensalmente.

Símbolos obrigatórios.

Perguntas secretas.

Regras absurdas.

Exemplos.

SenhaJan2026
SenhaFev2026
SenhaMar2026

O usuário apenas incrementava o mês.

Nada realmente melhorava.

Hoje.

O NIST recomenda.

Passphrases longas.

Bloqueio contra senhas vazadas.

MFA.

FIDO2.

Autenticação forte.


O IBM z17 e a era Passwordless

O IBM z17 representa outra etapa evolutiva.

O objetivo não é apenas fortalecer senhas.

É eliminar senhas.

Tecnologias disponíveis.

Certificados.

Smartcards.

PIV.

Kerberos.

RACF MFA.

Passkeys.

Tokens.

Biometria.


MFA: Dois sabres de luz são melhores que um

Autenticação multifator funciona porque exige mais de um elemento.

Algo que você sabe.

Passphrase.

Algo que possui.

Token.

Algo que é.

Biometria.

Um atacante pode roubar uma senha.

Pode até enganar um usuário.

Mas roubar múltiplos fatores simultaneamente é muito mais difícil.


IDs Técnicos também merecem atenção

Muitos ambientes possuem.

USRBATCH.

DB2ADM.

CICSSTC.

MQMGR.

FTPUSER.

Estas contas frequentemente permanecem anos sem revisão.

Grande erro.

Devemos utilizar.

Rotação automática.

Vault corporativo.

Segredos temporários.

Auditoria constante.


O Sysprog Padawan em 2026

O Padawan moderno não pode ser apenas especialista em JCL.

Ele precisa entender.

Zero Trust.

Identidade.

Criptografia.

OAuth.

JWT.

OpenID.

PKI.

MFA.

Threat Hunting.

SIEM.

Compliance.

Porque o papel do Sysprog mudou.

Ele deixou de ser apenas um operador do sistema.

Tornou-se um arquiteto de confiança digital.


A recomendação do Mestre Bellacosa

Se eu estivesse formando uma academia para Sysprogs Padawans em 2026, minhas recomendações seriam:

Usuário comum.

Passphrase com vinte caracteres.

Desenvolvedor.

Passphrase mais MFA.

Administrador RACF.

MFA obrigatório.

IDs privilegiados.

Certificados digitais.

APIs.

OAuth2.

Serviços automatizados.

Segredos rotacionados.

Parceiros externos.

Autenticação federada.


Considerações finais – A verdadeira lição do RACF

No final das contas, a discussão sobre Passwords versus Passphrases não trata apenas de matemática.

Também não trata apenas de criptografia.

Ela fala sobre pessoas.

Sobre hábitos.

Sobre comportamento.

Sobre cultura organizacional.

Sobre engenharia de confiança.

O RACF continua sendo um dos sistemas de controle de acesso mais sofisticados já construídos.

Mas nem mesmo um IBM z17 equipado com processadores criptográficos dedicados consegue proteger uma organização cujo administrador utiliza uma senha anotada em um caderno escondido sob o teclado.

A verdadeira segurança surge quando tecnologia, processos e pessoas trabalham em harmonia.

E talvez esta seja a maior lição para todo Sysprog Padawan.

Aprender comandos é importante.

Dominar SETROPTS é valioso.

Entender SURROGAT, FACILITY e OPERCMDS é fundamental.

Mas compreender que segurança é uma disciplina viva, que evolui constantemente diante de novas ameaças, é o que realmente separa um aprendiz de um Mestre da Ordem Mainframe.

E lembre-se sempre:

No IBM Z, a Força não está apenas no processador. Ela também está na credencial que impede o lado sombrio de assumir o controle da galáxia corporativa.

 

terça-feira, 9 de julho de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Padawan Avançado - Parte IV

 

Bellacosa Mainframe e os ponteiros de memoria em cobol Parte IV

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 4 – O Padawan Avançado

COBOL, Metal C, APIs, Buffers Compartilhados, JSON, MQ e as Técnicas Jedi de Alto Desempenho no IBM Z

Por Bellacosa Mainframe


"O Padawan aprende MOVE. O Cavaleiro aprende BASED. O Mestre aprende que um ponteiro pode conectar universos inteiros."

Mestre Bellacosa Sysprog Jedi


Introdução

Chegamos ao último módulo do Holocron dos Ponteiros COBOL.

Nas partes anteriores aprendemos:

Parte 1

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • AMODE

  • Heap

  • Stack

Parte 2

  • BASED

  • ALLOCATE

  • FREE

  • CEEGTST

  • Estruturas dinâmicas

Parte 3

  • SOC4

  • Memory Leak

  • Overlay

  • CEEDUMP

  • IPCS

  • Fault Analyzer

O jovem Padawan então pergunta:

Mestre...

Eu entendi os ponteiros.

Mas onde eles realmente são usados?

O mestre aponta para um gigantesco IBM z17.

E responde.

Em praticamente todos os lugares importantes.


O grande segredo

Poucos desenvolvedores percebem.

Mas produtos IBM utilizam ponteiros intensivamente.

Exemplos.

CICS

DB2

MQ

LE

z/OS

TCP/IP

JES2

JES3

RACF

SMF

VSAM

IMS

Todos.


O COBOL moderno

COBOL não vive sozinho.

Ele conversa.

Com:

C

Metal C

Assembler

Java

MQ

JSON

REST

Sockets


E o idioma dessa conversa é.

Ponteiros.


COBOL e C

Talvez seja o casamento mais comum.


C

Produz buffer.


COBOL

Consome.


Arquitetura.

C


↓

malloc()


↓

PTR



↓

COBOL


BASED

Exemplo conceitual

Programa C.

malloc(1024);

Retorna.

Endereço.


COBOL.

01 WS-PTR POINTER.

Recebe.


Associa.

SET ADDRESS OF BUFFER

TO WS-PTR

Pronto.


COBOL agora enxerga.

Memória criada em C.


Metal C

Mais interessante.


Executa próximo do hardware.


Pode usar.

64 bits.

Storage Keys.


Compartilhar.

Buffers.


Muito utilizado.

Middleware.


Shared Memory

Outro uso avançado.


Vários programas.

Mesmo buffer.


Visualmente.

Programa A


↓

Shared Buffer


↑


Programa B

Sem cópia.


Muito rápido.


MQ

Excelente exemplo.


MQGET

MQPUT


Mensagem.


Buffer.


COBOL.

Ponteiro.


Estrutura BASED.


Visualmente.

MQ


↓

Buffer


↓

PTR


↓

BASED

Processamento.

Zero cópia.


JSON

Muito utilizado hoje.


Imagine.

{
"name":"Bellacosa",

"idade":52
}

Parser.

Cria árvore.


Cada nó.

Possui ponteiros.


Pai.

Filho.

Irmão.


Exemplo.

JSON ROOT


↓


name


↓


idade

XML

Mesma ideia.


DOM.


Tree.


Ponteiros ligam.

Nós.


APIs

z/OS Connect.


Buffers.


Payload.


Parser.


Muito comum.


Sockets

TCP/IP.


Recebe.

4096 bytes.


Ponteiro.


COBOL lê.


Mais eficiente.


Cache

Outro caso.


Tabela gigante.


Ponteiro.

Evita copiar.


Exemplo.

100 MB.


Mover.

Custa.


Apontar.

8 bytes.


Quase instantâneo.


Tabelas in-memory

Excelente.


DB local.


Lookup rápido.


Hash.


B-tree.


Implementável.


Estruturas avançadas

Lista Duplamente Encadeada

NODE


PREV


NEXT

Árvore AVL


Balanceada.


Ponteiros.


B-tree

Muito utilizada.

Banco dados.


Grafo

Exemplo.

A


/ \


B  C


\ /


D

Tudo possível.


Comparação com outras linguagens

LinguagemPonteiros
COBOLSim
CSim
C++Sim
RustControlado
JavaReferências
GoSim
PythonOculto

Curiosidade

Java.

Esconde.


COBOL.

Mostra.


C.

Expõe totalmente.


Rust.

Protege.


Quando usar?

Bellacosa recomenda.


Excelente.

Buffers

MQ

JSON

XML

APIs

Cache

LE

Middleware

Parsers

Estruturas dinâmicas


Quando evitar?

Cadastro.


Folha pagamento.


VSAM simples.


DB2 comum.


Relatórios.


Performance

Muito alta.


Sem MOVE.


Sem COPY.


Sem serialização.


Muito usada.

Em produtos IBM.


Segurança

Ainda importante.


Ponteiro errado.

Continua.

SOC4.


Heap inválido.


Overlay.


Corrompe.


Documentação

Obrigatória.


Desenhe.

Diagramas.


Exemplo.

PTR1


↓

NODE1


↓

NODE2


↓

NODE3

Ajuda manutenção.


Bellacosa Best Practices

Regra 1

Inicialize.

Sempre.

SET PTR TO NULL

Regra 2

Documente.


Regra 3

Libere.


Regra 4

Nunca reutilize.

Após FREE.


Regra 5

BASED bem definido.


Regra 6

Evite engenharia excessiva.


O Teste do Mestre

Pergunta ao Padawan.

Você precisa.

Criar.

Lista encadeada?


Não?


Use OCCURS.


Sim?


Use ponteiros.


Curiosidades Finais

A maioria dos desenvolvedores COBOL jamais precisará escrever uma árvore AVL.

Ou um parser XML próprio.

Ou um cache compartilhado.

Ou uma estrutura dinâmica baseada em CEEGTST.

Mas os profissionais que sabem fazer isso normalmente pertencem a grupos bastante especializados:

  • Sysprogs

  • Middleware Engineers

  • Desenvolvedores CICS

  • Equipes MQ

  • Produtos IBM

  • Desenvolvedores de Frameworks

  • Especialistas em LE

  • Equipes de Modernização IBM Z


O Conselho Final do Mestre Bellacosa

Os ponteiros em COBOL são quase como cristais Kyber escondidos em uma antiga câmara do templo IBM Z.

Durante décadas, muitos desenvolvedores passaram por eles sem percebê-los.

Outros ouviram histórias assustadoras sobre SOC4, overlays e memory leaks e decidiram nunca tocá-los.

E alguns poucos escolheram estudá-los profundamente.

Esses poucos descobriram algo fascinante.

Ponteiros não servem apenas para criar problemas.

Eles são a base invisível que sustenta grande parte das tecnologias modernas do ecossistema IBM Z.

São eles que permitem compartilhar buffers entre linguagens.

São eles que fazem parsers navegarem por documentos JSON gigantescos.

São eles que ajudam produtos IBM a movimentar milhões de mensagens MQ por segundo.

São eles que transformam estruturas estáticas em sistemas vivos, capazes de crescer, adaptar-se e responder dinamicamente às necessidades do negócio.

Mas existe uma última lição.

Talvez a mais importante.

Um ponteiro não possui moral.

Ele não distingue sabedoria de imprudência.

Ele apenas aponta.

E cabe ao desenvolvedor decidir se está usando esse poder para construir um elegante mecanismo de alto desempenho ou para abrir um portal direto para um CEEDUMP de 500 páginas às três horas da manhã de um fechamento bancário.


Fim do Holocron Bellacosa Mainframe

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM ZParte 1 a Parte 4 concluídas.


terça-feira, 7 de maio de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas - Parte II

 

Brellacosa Mainframe e os ponteiros de memoria do Cobol parte II

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas

Quando o Padawan Descobre que Pode Construir Estruturas que Não Existem Até Serem Invocadas

Por Bellacosa Mainframe


"Um registro em WORKING-STORAGE nasce junto com o programa. Um registro BASED espera pacientemente até que alguém lhe conceda um endereço. É quase como invocar um sabre de luz que ainda não possui cristal."

Mestre Sysprog Bellacosa


Introdução

Na Parte 1 aprendemos sobre:

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • Stack

  • Heap

  • AMODE 24/31/64

  • Ponteiros inválidos

  • Dangling pointers

Agora vamos atravessar uma das fronteiras mais desconhecidas do COBOL moderno.

Chegou o momento do Padawan descobrir algo surpreendente.

No COBOL, podemos criar estruturas que não ocupam memória alguma até receberem um endereço válido.

Sim.

Existe praticamente uma espécie de objeto fantasma.

Uma descrição.

Uma planta arquitetônica.

Um molde.

Sem existência física.

Até alguém dizer:

SET ADDRESS OF ALGUMA-COISA

ou

ALLOCATE

E então...

A estrutura ganha vida.


O que é BASED?

BASED é provavelmente uma das palavras menos utilizadas no COBOL corporativo.

Exemplo:

01 WS-CLIENTE BASED.

O compilador entende:

"Existe uma estrutura chamada WS-CLIENTE."

Mas também entende:

"Não reserve memória para ela."


Diferença entre WS tradicional

Working Storage

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Ao carregar o programa.

Memória:

1000 WS-NOME

1030 WS-IDADE

Sempre existe.


BASED

01 WS-CLIENTE BASED.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Memória:

Nada.

Zero.

Inexistente.


Como BASED funciona?

Pense em um apartamento na planta.

Temos:

Sala

Cozinha

Banheiro

Quarto

Tudo desenhado.

Mas ainda não foi construído.


BASED é exatamente isso.


O papel do ponteiro

Precisamos de alguém para dizer:

Mestre...

O apartamento agora fica naquele endereço.


Exemplo

01 PTR-CLIENTE.

USAGE POINTER.

Associando

SET ADDRESS OF WS-CLIENTE

TO PTR-CLIENTE

Pronto.

WS-CLIENTE agora existe.


Primeiro exemplo completo

Passo 1

Definir ponteiro

01 PTR-CLI POINTER.

Passo 2

Criar estrutura BASED

01 REG-CLIENTE BASED.

   05 CLI-ID.
      PIC 9(5).

   05 CLI-NOME.
      PIC X(30).

   05 CLI-SALDO.
      PIC S9(7)V99.

Passo 3

Criar memória real

01 WS-AREA.

   PIC X(40).

Passo 4

Associar

SET PTR-CLI

TO ADDRESS OF WS-AREA

Passo 5

Ativar

SET ADDRESS OF REG-CLIENTE

TO PTR-CLI

Passo 6

Usar

MOVE 1000

TO CLI-ID


MOVE 'BELLACOSA'

TO CLI-NOME

Resultado.

Funciona.

Mesmo sendo BASED.


O que aconteceu?

Antes

REG-CLIENTE


inexistente

Depois

PTR-CLI


↓

70001000




REG-CLIENTE


usa memória 70001000

ALLOCATE

Agora começa a magia.

Não queremos usar WS.

Queremos memória nova.

Dinâmica.


Exemplo

ALLOCATE REG-CLIENTE

Compilador solicita memória.

Heap.


Visualmente

Antes

HEAP


vazio

Depois

HEAP


7000000


REG-CLIENTE

FREE

Toda magia tem preço.

Precisamos liberar.


Exemplo

FREE REG-CLIENTE

Se esquecer.

Memory leak.


CEEGTST

Muito utilizado.

LE Runtime.


Significa.

Get Storage.


Exemplo conceitual

CALL 'CEEGTST'

LE devolve.

Endereço.


Ponteiro recebe.


Mais sofisticado.

Mais profissional.


CEEFRET

Libera memória.


Equivalente.

malloc()


free()

No mundo C.


Comparação

COBOLC
ALLOCATEmalloc
FREEfree
CEEGTSTmalloc avançado
CEEFRETfree

Criando lista encadeada

Agora o lado Jedi aparece.


Estrutura

01 NODE BASED.


05 DADO.
PIC 9(5).


05 NEXT POINTER.

Visualmente

NODE


DADO


NEXT

Primeiro nó

100


PTR=2000

Segundo

200


PTR=3000

Terceiro

300


NULL

Ligando nós

SET NEXT

TO PTR-NODE2

Pronto.

Lista encadeada.


Navegando

Começamos.

HEAD

Enquanto

PTR <> NULL

Exibe.

Avança.


Exemplo

DISPLAY DADO


SET PTR

TO NEXT

Filas

Também possível.

FIFO.


Cliente 1

Cliente 2

Cliente 3


Pilhas

LIFO.


Push

Pop

Peek


Tudo em COBOL.


Árvores

Mais interessante.


          50


      20      80


   10   30

Estrutura

LEFT POINTER


RIGHT POINTER

Muito elegante.


Tabelas dinâmicas

Outra vantagem.


OCCURS tradicional.

1000 TIMES

Sempre ocupa.


Dinâmica.

Somente o necessário.


XML

Parser.


Nós.

Filhos.

Pai.


Ponteiros ajudam muito.


JSON

Excelente caso.


Objeto.

Array.

Subobjeto.


Estrutura árvore.


Performance

Muito boa.


Sem copiar dados.


Apenas endereço.


Mover.

8 bytes.


Mover.

1 MB.

Muito pior.


Heap

Mais lenta.

Que Working Storage.


Mas muito flexível.


Cuidados

Nunca esquecer FREE


Não usar memória liberada


Inicializar ponteiros

SET PTR TO NULL

Verificar retorno


Documentar


Curiosidade

Pouquíssimos desenvolvedores COBOL já implementaram uma lista encadeada real em produção.

Mas praticamente todos os produtos IBM utilizam estruturas semelhantes internamente.

CICS.

MQ.

DB2.

LE.

z/OS.

Todos.


O Conselho do Mestre Bellacosa

BASED é provavelmente a funcionalidade que mais aproxima COBOL do universo das linguagens de sistemas.

Ela permite abandonar parcialmente o modelo tradicional de registros fixos e entrar em um mundo onde estruturas podem nascer, crescer, conectar-se umas às outras e desaparecer dinamicamente.

Mas o jovem Padawan deve compreender uma verdade fundamental.

Quando utilizamos BASED, ALLOCATE, CEEGTST e ponteiros encadeados, deixamos o confortável universo dos datasets catalogados, dos OCCURS previsíveis e dos registros estáticos.

Passamos a caminhar pelos corredores escuros do Heap do Language Environment.

E nesses corredores existem criaturas perigosas chamadas:

  • Memory Leak

  • Dangling Pointer

  • Heap Corruption

  • S0C4

  • Storage Overlay

  • Abend U4038

O verdadeiro Mestre COBOL não teme essas criaturas.

Ele simplesmente sabe exatamente onde elas vivem.


Continua na Parte 3

O Lado Sombrio dos Ponteiros: SOC4, Memory Leaks, Dumps, IPCS, Fault Analyzer e os Monstros Escondidos no Heap do IBM Z.


segunda-feira, 15 de abril de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Despertar da Força dos Ponteiros - Parte I

 

Bellacosa Mainframe e os ponteiros de memoria no COBOL Parte I

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 1 – O Despertar da Força dos Ponteiros

Quando o Padawan Descobre que um Endereço Pode Ser Mais Poderoso que os Dados

Por Bellacosa Mainframe


"O dado é importante. Mas conhecer onde ele vive na memória é conhecer a própria Força."

Mestre Sysprog Bellacosa


Introdução

Existe um momento na jornada de todo desenvolvedor COBOL em que ele acredita já ter visto praticamente tudo.

Aprendeu arquivos.

Aprendeu VSAM.

Aprendeu DB2.

Aprendeu CICS.

Aprendeu tabelas OCCURS.

Aprendeu REDEFINES.

Aprendeu recursão.

Aprendeu programas aninhados.

Aprendeu até THREADSAFE.

Então um dia aparece um código semelhante a este:

01 PTR-CLIENTE      USAGE POINTER.

SET PTR-CLIENTE TO ADDRESS OF WS-CLIENTE.

O jovem Padawan olha para aquilo e pergunta:

Mestre…

COBOL tem ponteiros?

O mestre sorri.

Toma um gole de café.

E responde:

Sim.

E são provavelmente uma das funcionalidades menos conhecidas, mais poderosas e potencialmente mais perigosas disponíveis no IBM Enterprise COBOL.


O grande mito

Existe um mito muito comum.

"COBOL não trabalha com endereços."

Errado.

COBOL trabalha.

Sempre trabalhou.

Só que de forma extremamente controlada.

Enquanto linguagens como C permitem brincar livremente com memória:

int *p;

COBOL diz:

Jovem Padawan...

Se você vai manipular memória...

Faça isso com respeito.


O que é um ponteiro?

Um ponteiro não é um dado.

Ele não contém um nome.

Ele não contém um CPF.

Ele não contém uma data.

Ele contém:

O endereço onde algo está.

Imagine.

Apartamento:

Rua Jedi 500

Apartamento 1001

O apartamento é o dado.

O endereço é o ponteiro.


Exemplo.

Cliente

Nome

Bellacosa

Está armazenado em:

7FFF012345678

O ponteiro guarda:

7FFF012345678

Nada mais.


Por que isso existe?

Porque às vezes queremos acessar memória dinamicamente.

Criar estruturas.

Buffers.

Caches.

Árvores.

Filas.

Listas.

Comunicar com C.

Trabalhar com APIs.

Manipular XML.

Shared Memory.

LE Runtime.


COBOL sempre teve ponteiros?

Não.

COBOL 60

Não.

COBOL 68

Não.

COBOL 74

Não.


A situação começou a mudar com:

COBOL 85


Mais tarde.

IBM Enterprise COBOL.

Introduziu:

USAGE POINTER

ADDRESS OF

BASED

ALLOCATE

FREE


Atualmente.

Enterprise COBOL

4

5

6

6.3

6.4

6.5

Suportam totalmente.


O que é USAGE POINTER?

É o tipo especial que armazena um endereço.

Exemplo.

01 WS-PTR.

   USAGE POINTER.

ou

01 WS-PTR POINTER.

Não faça:

PIC X(08)

Errado.


Não faça:

PIC 9(18)

Errado.


O compilador conhece o formato.

Você não precisa.


ADDRESS OF

Talvez seja a instrução mais importante.

Exemplo.

Temos.

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).

Pegando endereço.

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Pronto.

Agora.

WS-PTR aponta.

Para WS-CLIENTE.


Visualmente

Antes.

WS-PTR


NULL

Depois.

WS-PTR


0000007FFF123450

Como funciona na memória

Imagine.

Working Storage

ENDEREÇO


1000


WS-NOME


Bellacosa



1030


WS-IDADE


52



1035


WS-PTR

Executamos.

SET PTR

TO ADDRESS OF WS-NOME

Resultado.

PTR


1000

O ponteiro virou.

Uma espécie de GPS.


O que é SET?

SET é o comando utilizado.

Para manipular ponteiros.

Exemplo.

SET PTR

TO ADDRESS OF WS-DADOS

Outro.

SET PTR TO NULL

Muito importante.

Sempre inicializar.


Boa prática.

SET PTR TO NULL

No início.


Primeiro exemplo completo

Passo 1

Criar estrutura

WORKING-STORAGE SECTION.


01 WS-CLIENTE.

   05 WS-NOME.

      PIC X(30).



01 WS-PTR

USAGE POINTER.

Passo 2

Preencher

MOVE 'BELLACOSA'

TO WS-NOME

Passo 3

Capturar endereço

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Passo 4

Display

DISPLAY 'PONTEIRO OK'

Fim.


O que o compilador faz?

Compilador cria.

Variável especial.

Compatível com arquitetura.

31 bits.

64 bits.


Padawan pergunta.

Mestre...

Então é um hexadecimal?

Resposta.

Sim.

Normalmente.


Exemplo.

0000000012345678

IBM Z e endereçamento

Aqui começa a magia.

IBM Z possui longa história.


AMODE 24

Década 70.

Memória.

16 MB.


AMODE 31

1983

2 GB


AMODE 64

zSeries

Exabytes teóricos.


COBOL acompanha.


Working Storage

Ponteiros podem apontar para:

Working Storage


Local Storage


Heap


Dynamically allocated


LE Areas


Buffers


Stack

Existe outra área.

Stack.

Exemplo.

Função chamada.

STACK



Frame A


Frame B


Frame C

Cada frame.

Possui.

Variáveis.

Retorno.

Contexto.


Ponteiros podem apontar.

Para stack.

Sim.


Mas aqui mora perigo.


O lado sombrio

Imagine.

Procedimento.

Termina.

Stack destruída.


Ponteiro ainda existe.


Aponta.

Para memória inválida.


Chamamos isso.

Dangling Pointer.


Exemplo.

PTR


12345

Memória já morreu.


Resultado.

SOC4.


Heap

Heap é diferente.

Sobrevive.

Mais tempo.


Usado em.

ALLOCATE.

CEEGTST.

GETMAIN.


Mais seguro.


Curiosidade

Muitos programas COBOL bancários.

Nunca usam ponteiros.


Por quê?

Não precisam.


COBOL nasceu.

Para registros.

Arquivos.

Campos fixos.


Ponteiros vieram.

Muito depois.


Vantagens

Extremamente rápidas.

Não copia dados.


Exemplo.

Mover.

1 MB.

Custa.

CPU.


Mover ponteiro.

8 bytes.

Instantâneo.


Onde usar?

Excelente para.

XML

JSON

Árvores

Cache

Filas

MQ

Buffers

APIs

Sockets

C

Metal C


Onde NÃO usar?

Cadastro clientes.

Folha pagamento.

Relatórios.

VSAM simples.

Batch convencional.


Performance

Muito boa.

Quase zero overhead.


Mas.

Erro custa caro.


Um MOVE errado.

Perde registro.


Ponteiro errado.

Pode derrubar programa.


SOC4.


Segurança

Ponteiros são ferramenta poderosa.

Mas perigosos.


Podem causar.

Corrupção memória.

Exposição dados.

Abends.

Memory leaks.


Padawan deve lembrar.

Ponteiro não sabe.

Se memória ainda existe.

Ele apenas acredita.


Curiosidades Bellacosa

Pouquíssimos desenvolvedores COBOL escrevem código com ponteiros diariamente.

Mas os profissionais que trabalham com:

  • Language Environment

  • XML parsers

  • CEEGTST

  • Metal C

  • DB2 internals

  • Middleware

  • MQ exits

  • CICS User Exits

  • z/OS Connect

  • Parsers de alta performance

frequentemente encontram USAGE POINTER, ADDRESS OF, BASED e estruturas dinâmicas escondidas em programas aparentemente inocentes.


O Conselho do Mestre Bellacosa

Imagine que os dados COBOL são sabres de luz.

Você pode segurá-los diretamente.

Pode copiá-los.

Pode movê-los.

Pode validá-los.

Mas um ponteiro é diferente.

Um ponteiro é um mapa para encontrar o sabre.

Ele não contém energia.

Ele não contém plasma.

Ele apenas diz:

"Vá até aquele lugar da memória e você encontrará aquilo que procura."

E essa é justamente a beleza e o perigo dos ponteiros em COBOL.

Eles permitem que o Padawan transcenda a programação tradicional baseada em registros fixos e passe a manipular a própria estrutura da memória do IBM Z.

Mas também ensinam uma das maiores lições do universo mainframe:

O dado pode estar protegido por RACF.

O dataset pode estar catalogado.

O programa pode ser RENT e THREADSAFE.

Mas um ponteiro errado continua tendo o poder de levar até mesmo um Mestre Sysprog ao temido S0C4.

Continua na Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas: Construindo Listas Encadeadas no IBM Z.


domingo, 10 de fevereiro de 2019

☕💥 A Jornada do Padawan COBOL – Parte 2 Desvendando o Universo dos CALLs no Mainframe Parte II

 

Bellacosa Mainframe explora o comando CALL no COBOLparte II

☕💥 A Jornada do Padawan COBOL – Parte 2

Desvendando o Universo dos CALLs no Mainframe

Os Segredos de BY REFERENCE, BY CONTENT, BY VALUE, Ponteiros, Work-Storage e Local-Storage

Ou como descobrir que um simples CALL pode criar um S0C4 capaz de assombrar um desenvolvedor por semanas

Por Vagner Bellacosa – Bellacosa Mainframe


A Hora em que o Padawan descobre que CALL não é magia

Na Parte 1 descobrimos que existem dois grandes reinos:

  • Static CALL

  • Dynamic CALL

Mas ainda falta compreender algo muito mais importante.

O que realmente acontece quando passamos dados para outro programa?

Porque é aqui que nascem aproximadamente 70% dos S0C4 que já vi em produção.

E quase todos começam com uma frase inocente:

"Só acrescentei um campo..."


O Grande Segredo do COBOL

Muitos desenvolvedores vindos de Java imaginam algo parecido com:

funcao(cliente);

Criou cópia.

Passou objeto.

Garbage Collector resolve.

No Mainframe não existe fada madrinha.

Existe endereço de memória.

E apenas endereço.


O padrão COBOL

O padrão do COBOL é:

BY REFERENCE

Mesmo quando você não escreve.

CALL 'SUBPGM'
USING WS-CLIENTE.

É equivalente a:

CALL 'SUBPGM'
USING BY REFERENCE WS-CLIENTE.

Como funciona na memória

Programa principal

MAIN

00010000


WS-NOME

JOAO

CALL

Passa:

00010000

Subprograma

LINKAGE


LK-NOME

Recebe

00010000

Mesmo local.


Diagrama


MAIN


WS-NOME
+---------+
| JOAO    |
+---------+

      |
      |
      V


SUBPGM


LK-NOME


+---------+
| JOAO    |
+---------+



A magia acontece

Subrotina

MOVE 'MARIA' TO LK-NOME

Retorno

Main

MARIA

Mudou.

Porque é o mesmo endereço.


Vantagens

Muito rápido

Pouca memória

Zero cópia

Ideal tabelas grandes

VSAM

DB2

Buffers


Desvantagens

Subprograma pode destruir dados.

Sem querer.

Ou querendo.


O pesadelo do suporte

Programa A

passa saldo

Programa B

zera saldo

Programa A

grava no DB2

Cliente perde dinheiro.


O truque Jedi

Criar cópia antes.

MOVE WS-AREA TO WS-BACKUP

Quando usar

Grandes estruturas

100 mil registros

buffers VSAM

SQLDA

COMMAREA


CALL BY CONTENT

Agora o Padawan ganha maturidade.

Quer proteger dados.


Exemplo

CALL 'VALIDA'

USING
BY CONTENT WS-DATA

O compilador cria

uma área temporária.


Na memória

Original

WS-DATA


20250623

Cópia

TEMP


20250623

Subprograma recebe

TEMP


Alterações desaparecem

Subprograma

MOVE ZEROS TO LK-DATA

Volta

Main

Continua

20250623


Vantagens

Segurança

Proteção

Imutabilidade


Desvantagens

Consome memória.

Faz cópia.

CPU extra.


Benchmark imaginário

Estrutura

2 MB

1000 chamadas

By Reference

2 MB

By Content

2000 MB movimentados


O Mestre Mainframe pensa

Preciso alterar?

Não.

By Content.

Preciso compartilhar?

Reference.


CALL BY VALUE

Pouco conhecido.

Muito poderoso.


Surge com LE.

Language Environment.


Exemplo

CALL 'MINHAROT'

USING
BY VALUE WS-ID

Subrotina recebe

valor.

Não endereço.


É muito usado com

C

Assembler

LE APIs


Exemplo famoso

CALL 'CEE3ABD'

USING
BY VALUE 4095

O universo dos Ponteiros

Padawan vê isso.

USAGE POINTER

E fica com medo.

Com razão.


Exemplo

01 PTR USAGE POINTER.

Setar endereço

SET PTR TO ADDRESS OF WS-CLIENTE

PTR

00001000

Pode passar

CALL 'ROTINA'

USING PTR

Subprograma

recebe

endereço bruto.


É perigoso?

Muito.


Erro clássico

PTR inválido.

Resultado

S0C4


S0C4 explicado

CPU tenta acessar

endereço inexistente.


Exemplo

00000000

Crash.


LINKAGE SECTION

O portal interdimensional do COBOL.


Exemplo

LINKAGE SECTION.


01 LK-CLIENTE.


05 LK-NOME.


05 LK-ID.

Procedure Division

PROCEDURE DIVISION USING LK-CLIENTE.

Não aloca memória.

Nunca.


Apenas mapeia.


Work-Storage

Existe durante toda execução.


Carregado

uma vez.


Ideal

cache

tabelas

constantes


Exemplo

WORKING-STORAGE SECTION.


01 WS-CONTADOR PIC 9(9).

Local-Storage

Poucos usam.

Deveriam usar mais.


É recriado.

Toda chamada.


Exemplo

LOCAL-STORAGE SECTION.


01 LS-AREA.


05 LS-TEMP.

Diferença

WS

Persiste.

LS

Nasce.

Morre.


Exemplo

Chamada 1

contador=1

Chamada 2

contador=0


Excelente para

subrotinas reentrantes.

CICS.

LE.

Threads.


Reentrant

IBM adora isso.


Programa

não compartilha estado.


Evita corrupção.


Compilar

RENT

Erros clássicos

S0C4

Parâmetro errado


S0C7

Campo inválido


U4038

LE erro


S806

Programa não encontrado


Como validar

Antes do CALL

IF WS-PGM = SPACES

DISPLAY 'ERRO'

STOP RUN

END-IF

Conferir quantidade de parâmetros

IBM fornece

CEE3PRM

Easter Egg IBM

Muitos bancos possuem

CALL 'GENERICA'

Dentro.

EVALUATE WS-CODIGO

Mais de 300 WHEN.

Documentação

nenhuma.

Autor

aposentado em 2003.

Programa

continua funcionando.

Ninguém toca.

É conhecido como:

O Dragão Adormecido do Mainframe™


Dicas Bellacosa Mainframe

Dica 1

By Reference

90% dos casos.


Dica 2

By Content

Dados protegidos.


Dica 3

By Value

LE.

C.

Assembler.


Dica 4

Local-Storage

Muito subestimado.


Dica 5

Nunca assumir layout.

Validar tamanho.


Dica 6

Documente interfaces.

Algo parecido com:

************************************************
* ENTRADA
* CLIENTE
* DATA
*
* SAIDA
* RC
************************************************

A Filosofia Jedi do CALL – Parte 2

O Padawan iniciante pensa:

"Passar parâmetro é fácil."

O desenvolvedor intermediário pensa:

"By Reference é mais rápido."

O Mestre Mainframe entende:

"Passagem de parâmetros é um contrato binário entre programas."

E sabe que uma única alteração aparentemente inocente, como adicionar um campo em uma estrutura passada por referência, pode fazer um sistema bancário inteiro produzir S0C4, S0C7, dados corrompidos, abends misteriosos e algumas noites muito longas acompanhadas por café requentado e dumps de 500 MB.

Na próxima parte da jornada, o Padawan descobrirá os segredos de RETURN-CODE, GOBACK, STOP RUN, CEE3DMP, IPCS, CEEDUMP, rastreamento de CALLs, técnicas avançadas de troubleshooting, otimização de performance, análise de dumps e as ferramentas secretas usadas pelos Mestres Jedi do z/OS para domar os dragões da produção.


sábado, 5 de janeiro de 1991

Relógio Cuco em Tempo Real: o Tempo, o Calendário e a Engenharia por Trás de um Clássico

Bellacosa Mainframe apresenta o relogio cuco suiço 

☕ Um Café no Bellacosa Mainframe

Relógio Cuco em Tempo Real: o Tempo, o Calendário e a Engenharia por Trás de um Clássico

Observe as horas passarem em um relógio cuco clássico, acompanhe os ponteiros de hora, minuto e segundo, consulte um calendário retrô e ouça as tradicionais badaladas que marcam os quartos de hora.

 

O relógio que transformou o tempo em movimento, som e memória

O tempo não pode ser segurado, armazenado em uma gaveta ou observado diretamente. Ainda assim, desde as primeiras civilizações, a humanidade procura maneiras de medi-lo, dividi-lo e representá-lo.

O movimento do Sol, as fases da Lua, as estações do ano, o crescimento das plantas, as marés e a alternância entre dia e noite foram alguns dos primeiros relógios naturais utilizados pelo ser humano.

Com o passar dos séculos, a observação da natureza deu origem a instrumentos cada vez mais precisos: relógios solares, clepsidras, ampulhetas, relógios mecânicos, relógios de pêndulo, cronômetros, relógios de quartzo, relógios atômicos e sistemas digitais sincronizados por redes de computadores.

O relógio cuco ocupa um lugar especial nessa história. Ele não apenas mostra as horas: também transforma o tempo em uma pequena apresentação mecânica. Portas se abrem, um pássaro aparece, o mecanismo se movimenta e um chamado anuncia que uma nova parte do dia acaba de chegar.

O simulador apresentado nesta página recria essa experiência diretamente no navegador. Ele combina um relógio analógico em tempo real, um calendário retrô, um pêndulo animado, um cuco em SVG e sons produzidos pelo próprio navegador.


O que é o tempo?

Em nossa vida cotidiana, o tempo é utilizado para organizar acontecimentos. Ele permite saber quando algo começou, quanto durou e em que ordem os eventos ocorreram.

Dizemos que uma reunião começa às nove horas, que uma viagem dura três horas ou que um documento foi criado em determinada data. Em todos esses casos, o tempo funciona como um sistema de referência.

Na física, o tempo participa da descrição dos movimentos, das mudanças e da relação entre os acontecimentos. Na astronomia, ajuda a acompanhar a rotação da Terra, sua órbita ao redor do Sol e os ciclos de outros corpos celestes.

Para o computador, o tempo é representado por números, contadores, frequências, registros e padrões de sincronização. Para nós, porém, ele também é memória, expectativa, rotina e experiência.

Um relógio mede intervalos. Um calendário organiza ciclos. A memória transforma ambos em história.

Por que o dia possui 24 horas?

A divisão do dia em 24 horas possui raízes muito antigas. Civilizações observavam o movimento aparente do Sol e das estrelas e dividiam o ciclo diário em diferentes períodos.

O sistema atual organiza um dia civil em:

  • 24 horas;
  • 1.440 minutos;
  • 86.400 segundos.

Cada hora possui 60 minutos, e cada minuto possui 60 segundos. Essa organização está associada à antiga tradição matemática sexagesimal, que utiliza o número 60 como base.

O número 60 é especialmente conveniente porque pode ser dividido por muitos valores inteiros, incluindo 2, 3, 4, 5, 6, 10, 12, 15, 20 e 30. Isso facilita a criação de metades, quartos, terços e outras frações do tempo.

 

Da sombra do Sol ao relógio mecânico

Relógios solares

Os relógios solares utilizavam a posição de uma sombra para indicar a passagem do dia. Embora simples, dependiam da luz solar e não funcionavam corretamente durante a noite ou em dias muito nublados.

Clepsidras e relógios de água

A clepsidra media o tempo por meio do fluxo controlado de água entre recipientes. Esse método possibilitava acompanhar intervalos mesmo sem a presença do Sol.

Ampulhetas

As ampulhetas utilizavam a passagem da areia por uma abertura estreita. Elas eram úteis para medir períodos determinados, mas precisavam ser viradas novamente após cada ciclo.

Relógios mecânicos

Os relógios mecânicos introduziram engrenagens, pesos, molas, sistemas de escape e reguladores. Esses componentes transformavam energia armazenada em movimentos regulares.

Em vez de depender diretamente do Sol ou do fluxo de um líquido, o relógio passou a carregar dentro de si um pequeno sistema dedicado a dividir o tempo.

 

Como funciona um relógio cuco clássico?

 

Um relógio cuco tradicional é uma máquina mecânica que integra medição do tempo, decoração, música e automação.

Entre seus principais elementos estão:

  • mostrador analógico;
  • ponteiros de hora e minuto;
  • engrenagens internas;
  • pesos suspensos por correntes;
  • pêndulo regulador;
  • fole responsável pelo som;
  • portinhola do cuco;
  • mecanismo de contagem das horas.

Os pesos fornecem energia ao mecanismo. Conforme descem, movimentam as engrenagens. O pêndulo controla a liberação dessa energia em pequenos intervalos regulares.

Na hora programada, uma sequência adicional de engrenagens abre a porta, movimenta o pássaro e aciona dois pequenos foles. Esses foles normalmente produzem duas notas sucessivas, criando o conhecido chamado do cuco.

Por que o cuco canta várias vezes na hora cheia?

Em muitos relógios tradicionais, a quantidade de chamados indica a hora. Às três horas, por exemplo, o cuco canta três vezes. Às doze horas, pode cantar doze vezes.

Esse recurso permitia identificar a hora pelo som, mesmo sem olhar para o mostrador. Em uma casa silenciosa, o relógio funcionava como uma espécie de anúncio sonoro distribuído pelo ambiente.


O que representam os ponteiros do relógio?

```

Ponteiro das horas

O ponteiro menor realiza uma volta completa a cada 12 horas. Ele não permanece parado entre dois números: move-se lentamente conforme os minutos avançam.

Ponteiro dos minutos

O ponteiro maior realiza uma volta completa a cada hora. Cada número do mostrador representa cinco minutos.

Ponteiro dos segundos

O ponteiro dos segundos completa uma volta a cada minuto. No simulador, seu movimento utiliza também as frações de segundo fornecidas pelo navegador, criando uma animação contínua.

Os ângulos dos ponteiros são calculados dinamicamente. O ponteiro das horas considera a posição dos minutos, enquanto o ponteiro dos minutos considera o avanço dos segundos.

```

Por que relógio e calendário são sistemas complementares?

```

O relógio organiza intervalos menores, como horas, minutos e segundos. O calendário organiza ciclos maiores, como dias, semanas, meses e anos.

Juntos, eles respondem a duas perguntas fundamentais:

  • Que horas são?
  • Que dia é hoje?

O calendário retrô incorporado ao simulador apresenta:

  • dia do mês;
  • dia da semana;
  • mês atual;
  • ano atual.

Essas informações são obtidas automaticamente pelo JavaScript a partir da data configurada no dispositivo do visitante.


A origem dos calendários

```

Os calendários surgiram da necessidade de acompanhar ciclos naturais. Povos antigos observavam fases lunares, estações, solstícios, equinócios, períodos de chuva, colheitas e movimentos dos astros.

Ao longo da história, diferentes sociedades criaram calendários solares, lunares e lunissolares. O calendário gregoriano, amplamente utilizado atualmente, organiza o ano em 12 meses e normalmente possui 365 dias.

A cada quatro anos, em grande parte dos casos, acrescenta-se um dia ao mês de fevereiro. Esse ajuste produz o chamado ano bissexto e ajuda a manter o calendário alinhado com o ciclo orbital da Terra.


Como funciona o simulador de relógio cuco?

```

O simulador foi construído com tecnologias nativas da web. Isso significa que ele não depende de bibliotecas externas, plugins ou arquivos de áudio hospedados em outros servidores.

HTML

O HTML organiza a estrutura do relógio, os controles, o painel digital, as informações do calendário e as mensagens de acessibilidade.

CSS

O CSS cria a aparência de madeira, metal, papel envelhecido e iluminação. Também controla o movimento do pêndulo, a abertura das portas e as animações do pássaro.

SVG

O SVG desenha o relógio diretamente no navegador. A casa, o mostrador, os números romanos, os ponteiros, o cuco, as correntes, os pesos e o calendário são elementos vetoriais.

Como são vetores, esses elementos podem ser ampliados ou reduzidos sem perder nitidez.

JavaScript

O JavaScript consulta a hora atual, calcula os ângulos dos ponteiros, atualiza o calendário, controla as animações e decide quando o cuco deve aparecer.

Web Audio API

O som do cuco é sintetizado no próprio navegador. Osciladores, filtros e controles de volume são combinados para produzir as notas, dispensando arquivos MP3.

```

Quando o cuco emite sons?

```

O comportamento sonoro do simulador segue quatro momentos principais:

Momento Tipo de chamado Finalidade
Hora cheia Longo e repetido Indicar a hora atual
15 minutos Curto Marcar o primeiro quarto de hora
30 minutos Semilongo Marcar a meia hora
45 minutos Curto Marcar o último quarto de hora

Na hora cheia, a quantidade de chamados corresponde à hora no formato de 12 horas. Dessa maneira, 15:00 produz três chamados, enquanto 00:00 pode produzir doze chamados.

```

Como utilizar o relógio cuco interativo

```
  1. Aguarde o carregamento completo da página.
  2. Observe os ponteiros sincronizados com a hora local.
  3. Consulte a data no calendário retrô.
  4. Clique em Ativar som.
  5. Use o botão de demonstração para testar o cuco.
  6. Utilize o botão de silenciar quando não quiser ouvir as badaladas.

O primeiro clique para ativar o som é necessário porque navegadores como Chrome, Edge, Firefox e Safari restringem a reprodução automática de áudio antes de uma interação do visitante.

```

O simulador mostra a hora correta?

```

O simulador utiliza o relógio interno do computador, tablet ou telefone. Portanto, sua precisão depende da configuração do dispositivo.

Quando o sistema operacional está sincronizado automaticamente com um servidor de horário, o relógio tende a acompanhar corretamente a hora oficial da região configurada.

O simulador também utiliza o fuso horário local do navegador. Um visitante em São Paulo poderá ver um horário diferente de outro visitante em Lisboa, Tóquio ou Nova York.

```

Fuso horário e horário de verão

```

O objeto de data do JavaScript considera as definições de fuso horário do sistema operacional. Quando uma região adota horário de verão e o dispositivo está atualizado, a mudança pode ser aplicada automaticamente.

Isso permite que o mesmo código funcione em diferentes países sem que seja necessário programar manualmente cada diferença de horário.

```

Como os computadores acompanham o tempo?

```

Sistemas computacionais geralmente armazenam datas e horários como valores numéricos. Um dos modelos mais conhecidos conta o tempo a partir de uma data de referência.

Aplicações transformam esses valores em anos, meses, dias, horas, minutos e segundos. Depois, aplicam o fuso horário e as regras regionais para apresentar uma data compreensível ao usuário.

Em sistemas distribuídos, a sincronização do tempo é especialmente importante. Registros de segurança, transações bancárias, mensagens, backups, eventos de rede e logs precisam manter uma ordem temporal confiável.

Um relógio incorreto pode fazer um evento parecer ter ocorrido antes de sua causa, dificultar auditorias ou produzir inconsistências entre servidores.


```

Curiosidades sobre relógios, calendários e cucos

```

1. O pêndulo não fornece energia ao relógio

O pêndulo regula o ritmo do mecanismo, mas a energia normalmente vem de pesos ou molas.

2. O som tradicional pode ser produzido por foles

Muitos relógios cuco utilizam dois foles, cada um responsável por uma nota. A sequência das duas notas cria o chamado característico.

3. Os pesos frequentemente lembram pinhas

Esse formato decorativo combina com a estética de floresta e madeira tradicionalmente associada aos relógios cuco.

4. O número romano quatro pode aparecer como IIII

Em vários mostradores, o número quatro é representado como IIII em vez de IV. Essa escolha pode melhorar o equilíbrio visual do mostrador.

5. Um relógio parado acerta a hora duas vezes por dia

Essa frase popular considera um mostrador de 12 horas. Mesmo sem se mover, sua indicação coincidirá com a hora real em dois momentos de cada dia.

6. Calendário e relógio resolvem escalas diferentes

O relógio acompanha ciclos curtos. O calendário organiza ciclos longos. A combinação dos dois permite registrar um instante com precisão.

7. O relógio cuco é uma forma antiga de automação residencial

Muito antes das casas inteligentes, o mecanismo já executava ações programadas: contava a hora, abria uma porta, movimentava uma figura e emitia sons.


```

O simulador como ferramenta educacional

```

O relógio cuco interativo pode ser utilizado para ensinar diferentes assuntos.

Matemática

  • ângulos;
  • frações;
  • divisão do círculo;
  • sistema sexagesimal;
  • proporções;
  • intervalos de tempo.

História

  • evolução dos instrumentos de medição;
  • origem dos calendários;
  • desenvolvimento da relojoaria;
  • automação mecânica.

Tecnologia

  • HTML semântico;
  • CSS responsivo;
  • animações;
  • SVG;
  • JavaScript;
  • Web Audio API;
  • acessibilidade digital.

Dessa forma, o simulador não é apenas decorativo. Ele também demonstra como conceitos de arte, engenharia, matemática e programação podem ser combinados em uma única aplicação web.

```

Por que este simulador é leve e performático?

```

O relógio foi projetado para funcionar sem bibliotecas externas. Isso reduz requisições adicionais e elimina a necessidade de carregar grandes frameworks.

Entre as características de desempenho estão:

  • desenho vetorial em SVG;
  • ausência de arquivos de áudio externos;
  • JavaScript executado localmente;
  • layout responsivo;
  • código isolado para evitar conflitos com o tema do Blogger;
  • animações controladas pelo navegador;
  • conteúdo textual legível por mecanismos de busca.

O texto desta postagem também permite que crawlers compreendam o tema da página mesmo quando não executam todas as animações do simulador.

```

Como o conteúdo pode ser compreendido por buscadores e sistemas de IA?

```

A página apresenta títulos hierárquicos, parágrafos explicativos, listas, tabela, perguntas frequentes, dados estruturados e descrição clara da aplicação.

Essa organização ajuda mecanismos como Google, Bing e Yahoo a identificar entidades e relações importantes, incluindo:

  • relógio cuco;
  • relógio analógico;
  • medição do tempo;
  • calendário;
  • ponteiros;
  • pêndulo;
  • simulador interativo;
  • aplicação educacional;
  • JavaScript;
  • SVG.

O SEO dinâmico incluído no início da postagem procura automaticamente a URL canônica, o título atual, a imagem principal e as datas disponíveis na página.

Dessa maneira, o código pode ser reutilizado sem exigir que cada endereço ou imagem seja inserido manualmente.

```

Perguntas frequentes

```

O simulador funciona no celular?

Sim. O layout é responsivo e o SVG ajusta seu tamanho conforme a largura disponível na tela.

É necessário instalar algum programa?

Não. O relógio funciona diretamente em navegadores modernos com suporte a HTML, CSS, SVG e JavaScript.

O simulador precisa de internet depois de carregado?

O funcionamento principal não depende de serviços externos. Entretanto, a página do Blogger precisa ser carregada inicialmente.

Por que o cuco não emite som automaticamente?

Os navegadores bloqueiam áudio automático antes da primeira interação. Clique no botão de ativação para liberar as badaladas.

Quando o cuco aparece?

Ele aparece na hora cheia, aos 15 minutos, aos 30 minutos e aos 45 minutos. Também pode ser acionado pelo botão de demonstração.

O relógio considera o fuso horário?

Sim. Ele utiliza o fuso horário configurado no dispositivo do visitante.

O calendário muda automaticamente à meia-noite?

Sim. Como a data é consultada continuamente, o calendário é atualizado quando o dispositivo passa para o dia seguinte.

O código pode ser usado em uma postagem do Blogspot?

Sim. O simulador e o artigo foram preparados para inserção no editor HTML do Blogger.

```

O tempo continua passando, mas agora podemos observá-lo

```

O relógio cuco representa uma época em que engenharia, artesanato e decoração ocupavam o mesmo espaço. Cada engrenagem tinha uma função, cada peso fornecia energia e cada movimento fazia parte de uma sequência cuidadosamente planejada.

Ao recriar esse mecanismo no navegador, transformamos engrenagens em JavaScript, madeira em SVG, foles em osciladores de áudio e movimentos mecânicos em animações CSS.

O resultado é uma ponte entre dois mundos: a relojoaria tradicional e a programação moderna.

O pêndulo continua balançando. Os ponteiros continuam avançando. O calendário muda silenciosamente. E, a cada quarto de hora, o pequeno guardião da casa abre sua porta para lembrar que o tempo não parou.

Em um relógio cuco, o tempo não apenas passa. Ele abre uma porta, canta e depois volta para dentro da memória.
```

Relógio Cuco Clássico

Hora local, calendário retrô e badaladas automáticas

CUCO XII I II III IV V VI VII VIII IX X XI 05 QUARTA-FEIRA AGOSTO 2026
00:00:00 Carregando data...
Som aguardando ativação
Hora cheia Cuco longo e repetido conforme a hora
30 minutos Chamado semilongo
15 e 45 minutos Chamado curto
Relógio sincronizado com a hora local.
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...