Translate

sábado, 14 de dezembro de 2019

O Mistério do Arquivo que Nunca Pulava uma Linha : Como OPEN, READ, PROCESS, WRITE e CLOSE Mantêm o Mundo Financeiro Funcionando Enquanto a Cidade Dorme

 

Bellacosa Mainframe e o misterio do arquivo que nunca pulava uma linha

☕ Um Café no Bellacosa Mainframe

O Mistério do Arquivo que Nunca Pulava uma Linha

Como OPEN, READ, PROCESS, WRITE e CLOSE Mantêm o Mundo Financeiro Funcionando Enquanto a Cidade Dorme

A chuva caía fina sobre os telhados da cidade.

Lá fora, os últimos ônibus atravessavam avenidas quase vazias. As luzes dos escritórios já tinham sido apagadas, os gerentes haviam ido embora, os clientes dormiam convencidos de que o dinheiro continuava imóvel dentro dos bancos e os relógios avançavam silenciosamente em direção à madrugada.

Mas, no subsolo de um grande centro de processamento, as máquinas continuavam acordadas.

O operador do turno da noite segurava uma caneca de café já frio. Diante dele, telas negras exibiam letras verdes, números de jobs, nomes de datasets e mensagens do JES2. Um processamento importante estava prestes a começar.

Milhões de transações realizadas durante o dia seriam lidas, verificadas, calculadas, separadas e gravadas novamente.

Uma por uma.

Sem atalhos.

Sem improvisações.

Sem saltar registros.

Era o trabalho perfeito para o COBOL.

Naquela noite, um jovem programador chamado Arthur seria apresentado a um dos mecanismos mais antigos, simples e poderosos do mundo corporativo:

o processamento de arquivos sequenciais.

Ele ainda não sabia, mas estava prestes a descobrir que boa parte da economia moderna depende de um ciclo aparentemente humilde:

OPEN
READ
PROCESS
WRITE
CLOSE

Cinco palavras.

Cinco portas.

Cinco etapas que, executadas corretamente, podem processar milhões de registros durante uma única madrugada.


1. O arquivo que guardava tudo em ordem

Arthur observou o analista mais velho abrir um membro no editor ISPF.

— Este é o arquivo de transações do dia — disse o veterano.

Na tela apareciam linhas com tamanhos fixos:

0000000001PIX  000012500CLIENTE000001CLIENTE00098720260729
0000000002TED  000250000CLIENTE000122CLIENTE00145620260729
0000000003BOL  000008990CLIENTE000834EMPRESA00005520260729
0000000004SAQ  000050000CLIENTE000912ATM00000002320260729

Cada linha era um registro.

Cada registro representava uma ocorrência de negócio.

Uma transferência.

Um pagamento.

Um saque.

Uma operação realizada por alguém em algum lugar do país.

Aquelas linhas não estavam espalhadas aleatoriamente. Elas estavam armazenadas uma após a outra, em uma sequência definida.

Esse é o princípio básico de um arquivo sequencial.

Um arquivo sequencial armazena registros consecutivamente. Para chegar ao registro número 500, o programa normalmente precisa passar pelos 499 registros anteriores.

É como ler um romance.

Você começa na primeira página.

Depois lê a segunda.

Depois a terceira.

Não se chega naturalmente à solução do mistério começando pela página 317.

No mundo COBOL, o programa lê um registro, processa aquele conteúdo e segue para o próximo.

REGISTRO 1
REGISTRO 2
REGISTRO 3
REGISTRO 4
...
REGISTRO N

A simplicidade desse modelo é exatamente o que o torna tão eficiente para grandes processamentos em lote.


2. Sequencial não significa ultrapassado

Muitos iniciantes cometem um erro de julgamento.

Ao ouvir a palavra “sequencial”, imaginam algo lento, antigo e inferior a bancos de dados modernos.

Nada poderia estar mais distante da realidade.

Arquivos sequenciais continuam extremamente úteis quando o objetivo é processar praticamente todos os registros de um conjunto de dados.

Imagine uma empresa que precisa calcular a folha de pagamento de 200 mil funcionários.

Ela não quer localizar apenas um funcionário.

Ela quer processar todos.

Nesse caso, ler o arquivo inteiro sequencialmente é uma estratégia lógica e eficiente.

O mesmo vale para:

  • fechamento bancário;

  • cálculo de juros;

  • emissão de faturas;

  • geração de extratos;

  • consolidação contábil;

  • processamento de apólices;

  • cálculo de comissões;

  • envio de informações fiscais;

  • classificação de transações;

  • produção de relatórios gerenciais.

O arquivo sequencial não tenta ser uma solução para tudo.

Ele é uma solução excelente para aquilo que foi criado para fazer:

processar grandes volumes de registros em ordem.


3. A herança das fitas magnéticas

Para entender a força do processamento sequencial, é preciso visitar o passado.

Nas décadas iniciais da computação comercial, muitos dados eram armazenados em fitas magnéticas.

A fita era um meio naturalmente sequencial.

Para acessar um registro localizado no meio dela, era necessário avançar fisicamente pelos dados anteriores.

Algo parecido com uma fita cassete.

Quem viveu a era das fitas de áudio sabe como funcionava.

Para ouvir a quinta música, você precisava avançar a fita até o ponto correto. Não havia um índice eletrônico instantâneo como em um aplicativo moderno.

Os primeiros sistemas corporativos foram construídos respeitando essa característica.

E o COBOL nasceu exatamente nesse ambiente.

Por isso, seu modelo de processamento de arquivos é tão natural:

ABRIR A FITA
LER UM REGISTRO
PROCESSAR
LER O PRÓXIMO
PROCESSAR
CONTINUAR ATÉ O FIM
FECHAR A FITA

Mesmo quando os discos substituíram as fitas em muitos cenários, o modelo continuou útil.

Hoje, o dataset pode estar em disco, em armazenamento virtualizado ou em uma infraestrutura moderna de alta velocidade. Ainda assim, o programa pode tratá-lo como um fluxo ordenado de registros.

A tecnologia física mudou.

A lógica permaneceu.


4. A anatomia de um programa COBOL com arquivo

O veterano apontou para a estrutura do programa.

— Para um arquivo existir dentro do COBOL, você precisa apresentá-lo formalmente ao programa.

Um programa de arquivo sequencial envolve várias divisões e seções importantes.

Normalmente, encontramos:

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

Cada parte possui uma responsabilidade.

IDENTIFICATION DIVISION

Identifica o programa.

IDENTIFICATION DIVISION.
PROGRAM-ID. RELATORIO-FUNCIONARIOS.

Aqui o programa recebe um nome.

Parece apenas burocracia, mas nomes são importantes em ambientes corporativos. Eles ajudam na compilação, catalogação, documentação e manutenção.

ENVIRONMENT DIVISION

Relaciona o programa com o ambiente externo.

É aqui que o arquivo lógico do COBOL é associado a uma identificação externa.

ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.
FILE-CONTROL.

    SELECT EMPLOYEE-FILE
        ASSIGN TO EMPFILE
        ORGANIZATION IS SEQUENTIAL
        FILE STATUS IS WS-EMP-STATUS.

Observe os elementos.

SELECT EMPLOYEE-FILE

Define o nome lógico que o programa utilizará.

ASSIGN TO EMPFILE

Relaciona o arquivo COBOL ao nome externo usado pelo ambiente de execução.

Em um job z/OS, esse nome geralmente se conecta a um DD statement do JCL.

ORGANIZATION IS SEQUENTIAL

Declara que o arquivo será tratado sequencialmente.

FILE STATUS IS WS-EMP-STATUS

Define uma variável que receberá o resultado de cada operação realizada sobre o arquivo.

Esse último item é fundamental para programas de produção.


5. O elo entre COBOL e JCL

O COBOL conhece o nome lógico.

O JCL conhece o dataset físico.

Essa ligação ocorre por meio do DDNAME.

No COBOL:

SELECT EMPLOYEE-FILE
    ASSIGN TO EMPFILE.

No JCL:

//EMPFILE  DD DSN=EMPRESA.RH.FUNCIONARIOS,
//            DISP=SHR

O COBOL diz:

“Quero trabalhar com EMPFILE.”

O JCL responde:

“EMPFILE corresponde ao dataset EMPRESA.RH.FUNCIONARIOS.”

Essa separação é extremamente poderosa.

O programa não precisa conhecer o nome físico definitivo do arquivo.

Em desenvolvimento, o mesmo programa pode usar:

DSN=DEV.RH.FUNCIONARIOS

Em homologação:

DSN=HML.RH.FUNCIONARIOS

Em produção:

DSN=PRD.RH.FUNCIONARIOS

O código COBOL permanece o mesmo.

Apenas o JCL muda.

É uma forma antiga e elegante de desacoplamento entre programa e ambiente.

Muito antes de a palavra “configuração externa” virar moda em arquiteturas modernas, o mainframe já fazia isso.


6. A FILE SECTION e o formato do registro

Na DATA DIVISION, o programa descreve como cada registro deve ser interpretado.

DATA DIVISION.

FILE SECTION.

FD  EMPLOYEE-FILE.

01  EMPLOYEE-RECORD.
    05 EMP-ID          PIC 9(5).
    05 EMP-NAME        PIC X(30).
    05 EMP-DEPARTMENT  PIC X(10).
    05 EMP-SALARY      PIC 9(7)V99.

O FD significa File Description.

Ele apresenta as características lógicas do arquivo.

Logo abaixo, temos o layout do registro.

01 EMPLOYEE-RECORD.

Esse grupo representa o registro completo lido do arquivo.

Os campos internos descrevem posições específicas.

05 EMP-ID PIC 9(5).

Número do funcionário com cinco dígitos.

05 EMP-NAME PIC X(30).

Nome com trinta caracteres.

05 EMP-DEPARTMENT PIC X(10).

Departamento com dez caracteres.

05 EMP-SALARY PIC 9(7)V99.

Salário com sete dígitos inteiros e duas casas decimais implícitas.

O V não ocupa uma posição física no arquivo. Ele representa uma vírgula decimal lógica.

Por exemplo, o conteúdo:

000350000

pode representar:

R$ 3.500,00

dependendo da definição do campo.

É importante observar que o arquivo sequencial normalmente não carrega separadores visuais entre campos.

O programa sabe onde cada campo começa e termina graças ao layout.


7. Um registro é uma fotografia do negócio

Cada registro pode ser visto como uma pequena fotografia de um evento corporativo.

Em uma folha de pagamento:

FUNCIONÁRIO
SALÁRIO
DEPARTAMENTO
HORAS EXTRAS
DESCONTOS

Em uma transação bancária:

CONTA
AGÊNCIA
VALOR
TIPO DE OPERAÇÃO
DATA

Em um sistema de seguros:

APÓLICE
CLIENTE
PRÊMIO
COBERTURA
VIGÊNCIA

O COBOL lê essa fotografia e interpreta cada pedaço segundo as regras do layout.

Se o layout estiver errado, a interpretação estará errada.

Um campo de valor pode ser lido como data.

Um nome pode invadir o campo de departamento.

Um código pode ficar deslocado.

Por isso, conhecer o layout do arquivo é uma das tarefas mais importantes para qualquer programador COBOL.

Em muitos incidentes de produção, o programa está tecnicamente correto.

O problema é que o arquivo recebido não respeita o layout esperado.


8. OPEN: a porta do arquivo

Nenhuma operação pode começar antes do OPEN.

OPEN INPUT EMPLOYEE-FILE

O OPEN prepara o arquivo para uso.

Ele informa ao ambiente de execução qual será o tipo de acesso.

Existem quatro modos principais.

OPEN INPUT

Usado para leitura.

OPEN INPUT EMPLOYEE-FILE

Operações típicas:

READ EMPLOYEE-FILE

O programa não pode gravar nesse arquivo.

OPEN OUTPUT

Usado para criar ou preparar um arquivo de saída.

OPEN OUTPUT REPORT-FILE

Depois, o programa pode executar:

WRITE REPORT-RECORD

É preciso atenção.

Em muitos cenários, abrir um arquivo como OUTPUT significa iniciar um novo conteúdo. O arquivo anterior pode ser substituído conforme a configuração do ambiente.

OPEN EXTEND

Usado para acrescentar registros ao final de um arquivo existente.

OPEN EXTEND LOG-FILE

É útil para arquivos de log ou históricos acumulativos.

OPEN I-O

Usado quando o programa precisa ler e atualizar o arquivo.

OPEN I-O CUSTOMER-FILE

Esse modo é mais comum em arquivos que suportam atualização apropriada, como certos cenários com VSAM.

Em arquivos sequenciais tradicionais, atualizações no meio do arquivo exigem estratégias específicas e frequentemente envolvem a geração de um novo arquivo.


9. O FILE STATUS: o informante que nunca deve ser ignorado

O veterano aproximou a cadeira.

— Programador iniciante acredita que um OPEN sempre funciona. Programador experiente pergunta o que aconteceu depois do OPEN.

Para isso existe o FILE STATUS.

01 WS-EMP-STATUS PIC XX.

Após uma operação:

OPEN INPUT EMPLOYEE-FILE

o programa verifica:

IF WS-EMP-STATUS NOT = '00'
    DISPLAY 'ERRO NO OPEN: ' WS-EMP-STATUS
    STOP RUN
END-IF

O código "00" normalmente indica sucesso.

Outros códigos podem indicar situações como:

  • arquivo inexistente;

  • modo de acesso incorreto;

  • fim do arquivo;

  • registro duplicado;

  • arquivo não aberto;

  • erro lógico ou físico.

O FILE STATUS é uma testemunha silenciosa.

Ele não impede o erro.

Mas informa exatamente que algo não saiu como esperado.

Ignorá-lo é como investigar um crime e desprezar a única pessoa que viu o suspeito.


10. READ: um registro de cada vez

Após abrir o arquivo, o programa começa a leitura.

READ EMPLOYEE-FILE

Cada READ transfere um registro do arquivo para a área definida na FILE SECTION.

O programa não recebe o arquivo inteiro.

Recebe apenas o registro atual.

Exemplo:

Arquivo:

00001ARTHUR COSTA                  TI        000750000
00002MARIA SILVA                   RH        000620000
00003JOAO PEREIRA                  FIN       000810000

Primeiro READ:

EMP-ID         = 00001
EMP-NAME       = ARTHUR COSTA
EMP-DEPARTMENT = TI
EMP-SALARY     = 000750000

Segundo READ:

EMP-ID         = 00002
EMP-NAME       = MARIA SILVA
EMP-DEPARTMENT = RH
EMP-SALARY     = 000620000

Cada leitura substitui o conteúdo anterior da área do registro.

Se o programa precisa preservar dados de registros anteriores, deve movê-los para variáveis de trabalho ou acumuladores.


11. O fim do arquivo: AT END

Todo arquivo termina.

O programa precisa saber quando não existem mais registros.

READ EMPLOYEE-FILE
    AT END
        MOVE 'Y' TO WS-END-OF-FILE
END-READ

Uma flag simples pode controlar todo o loop.

01 WS-END-OF-FILE PIC X VALUE 'N'.

Enquanto o valor for "N", ainda existem registros a processar.

Quando se torna "Y", a leitura terminou.

Uma abordagem tradicional é:

PERFORM UNTIL WS-END-OF-FILE = 'Y'
    READ EMPLOYEE-FILE
        AT END
            MOVE 'Y' TO WS-END-OF-FILE
        NOT AT END
            PERFORM PROCESS-EMPLOYEE
    END-READ
END-PERFORM

Essa estrutura é clara e segura.

O processamento ocorre apenas quando o READ realmente encontrou um registro.


12. A leitura antecipada

Existe outra técnica muito comum em COBOL batch.

Ela é chamada informalmente de priming read, ou leitura inicial.

O programa faz uma leitura antes do loop.

PERFORM READ-EMPLOYEE

PERFORM UNTIL WS-END-OF-FILE = 'Y'
    PERFORM PROCESS-EMPLOYEE
    PERFORM READ-EMPLOYEE
END-PERFORM

O parágrafo de leitura:

READ-EMPLOYEE.

    READ EMPLOYEE-FILE
        AT END
            MOVE 'Y' TO WS-END-OF-FILE
        NOT AT END
            ADD 1 TO WS-READ-COUNT
    END-READ.

Essa abordagem separa melhor as responsabilidades.

O loop principal fica fácil de entender:

LER O PRIMEIRO
ENQUANTO NÃO TERMINAR
    PROCESSAR
    LER O PRÓXIMO
FIM

É um padrão extremamente comum em programas COBOL tradicionais.


13. PROCESS: onde mora a inteligência do negócio

O arquivo apenas fornece dados.

O parágrafo de processamento decide o que fazer com eles.

PROCESS-EMPLOYEE.

    IF EMP-SALARY > 000700000
        ADD 1 TO WS-HIGH-SALARY-COUNT
    END-IF.

Mas programas reais fazem muito mais.

Podem:

  • calcular impostos;

  • verificar faixas salariais;

  • aplicar juros;

  • classificar clientes;

  • validar códigos;

  • detectar inconsistências;

  • acumular totais;

  • produzir registros de erro;

  • decidir qual arquivo receberá o registro;

  • montar linhas de relatório.

Exemplo de cálculo de bônus:

IF EMP-DEPARTMENT = 'VENDAS'
    COMPUTE WS-BONUS = EMP-SALARY * 0.10
ELSE
    COMPUTE WS-BONUS = EMP-SALARY * 0.05
END-IF

Suponha um salário de:

R$ 5.000,00

Para o departamento de vendas:

Bônus = R$ 500,00

Para outro departamento:

Bônus = R$ 250,00

O COBOL é particularmente forte nesse tipo de regra clara, determinística e repetitiva.


14. Acumuladores e contadores

Programas de arquivo sequencial quase sempre utilizam contadores e acumuladores.

Contador de registros lidos

ADD 1 TO WS-READ-COUNT

Contador de registros gravados

ADD 1 TO WS-WRITE-COUNT

Acumulador de valores

ADD EMP-SALARY TO WS-TOTAL-SALARY

No final, o programa pode exibir:

REGISTROS LIDOS    : 00000200
REGISTROS GRAVADOS : 00000198
REGISTROS REJEITADOS: 00000002
TOTAL DE SALÁRIOS  : R$ 945.300,00

Esses totais são importantes para reconciliação.

Se foram lidos 200 registros, mas apenas 198 foram gravados, os outros dois precisam estar explicados.

Talvez tenham sido rejeitados.

Talvez tenham sido enviados para um arquivo de erros.

Talvez exista um defeito.

Em produção, números de controle são pistas essenciais.


15. WRITE: transformando processamento em resultado

Depois de processar um registro, o programa pode gravar uma saída.

WRITE REPORT-RECORD

Antes do WRITE, normalmente o programa monta o registro de saída.

MOVE EMP-ID         TO OUT-EMP-ID
MOVE EMP-NAME       TO OUT-EMP-NAME
MOVE EMP-SALARY     TO OUT-EMP-SALARY
MOVE WS-BONUS       TO OUT-BONUS

WRITE REPORT-RECORD

O arquivo de saída pode ter um layout diferente do arquivo de entrada.

Entrada:

ID
NOME
DEPARTAMENTO
SALÁRIO

Saída:

ID
NOME
SALÁRIO
BÔNUS
SALÁRIO FINAL

Esse é um dos padrões mais clássicos do batch:

ARQUIVO DE ENTRADA
        ↓
   PROGRAMA COBOL
        ↓
ARQUIVO DE SAÍDA

O programa atua como uma máquina de transformação.


16. Arquivos de rejeição

Programas robustos não encerram necessariamente por causa de um único registro inválido.

Em muitos casos, o registro problemático é enviado para um arquivo separado.

IF EMP-ID IS NOT NUMERIC
    MOVE EMPLOYEE-RECORD TO REJECT-RECORD
    WRITE REJECT-RECORD
    ADD 1 TO WS-REJECT-COUNT
ELSE
    PERFORM PROCESS-VALID-EMPLOYEE
END-IF

Assim, o processamento principal continua.

No final, uma equipe pode analisar os registros rejeitados.

Esse desenho é comum em integrações de grande volume.

Um arquivo com um milhão de registros não deve necessariamente ser descartado inteiro porque três linhas estão incorretas.

Tudo depende da regra de negócio e do nível de criticidade.


17. CLOSE: o último ato do caso

Depois do último registro, os arquivos precisam ser fechados.

CLOSE EMPLOYEE-FILE
      REPORT-FILE
      REJECT-FILE

O CLOSE faz mais do que encerrar formalmente o uso.

Ele permite que o sistema:

  • descarregue buffers pendentes;

  • finalize gravações;

  • libere recursos;

  • complete operações de entrada e saída;

  • mantenha a consistência do arquivo.

Um programa disciplinado abre, usa e fecha corretamente seus arquivos.

O CLOSE é o momento em que o detetive guarda as provas, fecha o armário e registra oficialmente o fim da investigação.


18. Um programa completo comentado

A seguir, um exemplo didático.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. EMPREPORT.

       ENVIRONMENT DIVISION.

       INPUT-OUTPUT SECTION.
       FILE-CONTROL.

           SELECT EMPLOYEE-FILE
               ASSIGN TO EMPFILE
               ORGANIZATION IS SEQUENTIAL
               FILE STATUS IS WS-EMP-STATUS.

           SELECT REPORT-FILE
               ASSIGN TO REPORT
               ORGANIZATION IS SEQUENTIAL
               FILE STATUS IS WS-REP-STATUS.

       DATA DIVISION.

       FILE SECTION.

       FD  EMPLOYEE-FILE.

       01  EMPLOYEE-RECORD.
           05 EMP-ID              PIC 9(5).
           05 EMP-NAME            PIC X(30).
           05 EMP-DEPARTMENT      PIC X(10).
           05 EMP-SALARY          PIC 9(7)V99.

       FD  REPORT-FILE.

       01  REPORT-RECORD.
           05 OUT-EMP-ID          PIC 9(5).
           05 FILLER              PIC X VALUE SPACE.
           05 OUT-EMP-NAME        PIC X(30).
           05 FILLER              PIC X VALUE SPACE.
           05 OUT-BONUS           PIC 9(7)V99.

       WORKING-STORAGE SECTION.

       01  WS-END-OF-FILE         PIC X VALUE 'N'.
           88 END-OF-FILE         VALUE 'Y'.
           88 NOT-END-OF-FILE     VALUE 'N'.

       01  WS-EMP-STATUS          PIC XX.
       01  WS-REP-STATUS          PIC XX.

       01  WS-BONUS               PIC 9(7)V99 VALUE ZERO.

       01  WS-COUNTERS.
           05 WS-READ-COUNT       PIC 9(9) VALUE ZERO.
           05 WS-WRITE-COUNT      PIC 9(9) VALUE ZERO.

       PROCEDURE DIVISION.

       MAIN-PROCESS.

           PERFORM OPEN-FILES

           IF WS-EMP-STATUS = '00'
              AND WS-REP-STATUS = '00'

               PERFORM READ-EMPLOYEE

               PERFORM UNTIL END-OF-FILE
                   PERFORM PROCESS-EMPLOYEE
                   PERFORM WRITE-REPORT
                   PERFORM READ-EMPLOYEE
               END-PERFORM

           END-IF

           PERFORM CLOSE-FILES
           PERFORM DISPLAY-TOTALS

           STOP RUN.

       OPEN-FILES.

           OPEN INPUT  EMPLOYEE-FILE
                OUTPUT REPORT-FILE

           IF WS-EMP-STATUS NOT = '00'
               DISPLAY 'ERRO OPEN EMPFILE: ' WS-EMP-STATUS
           END-IF

           IF WS-REP-STATUS NOT = '00'
               DISPLAY 'ERRO OPEN REPORT: ' WS-REP-STATUS
           END-IF.

       READ-EMPLOYEE.

           READ EMPLOYEE-FILE
               AT END
                   SET END-OF-FILE TO TRUE
               NOT AT END
                   ADD 1 TO WS-READ-COUNT
           END-READ.

       PROCESS-EMPLOYEE.

           IF EMP-DEPARTMENT = 'VENDAS'
               COMPUTE WS-BONUS = EMP-SALARY * 0.10
           ELSE
               COMPUTE WS-BONUS = EMP-SALARY * 0.05
           END-IF.

       WRITE-REPORT.

           INITIALIZE REPORT-RECORD

           MOVE EMP-ID     TO OUT-EMP-ID
           MOVE EMP-NAME   TO OUT-EMP-NAME
           MOVE WS-BONUS   TO OUT-BONUS

           WRITE REPORT-RECORD

           IF WS-REP-STATUS = '00'
               ADD 1 TO WS-WRITE-COUNT
           ELSE
               DISPLAY 'ERRO WRITE REPORT: ' WS-REP-STATUS
           END-IF.

       CLOSE-FILES.

           CLOSE EMPLOYEE-FILE
                 REPORT-FILE.

       DISPLAY-TOTALS.

           DISPLAY 'REGISTROS LIDOS   : ' WS-READ-COUNT
           DISPLAY 'REGISTROS GRAVADOS: ' WS-WRITE-COUNT.

Esse programa ilustra os principais conceitos:

  • definição do arquivo;

  • associação externa;

  • layout do registro;

  • FILE STATUS;

  • abertura;

  • leitura;

  • detecção de fim;

  • processamento;

  • gravação;

  • fechamento;

  • contagem de registros.


19. O fluxo mental que o iniciante deve dominar

Antes de escrever qualquer código, desenhe o fluxo.

INÍCIO
  |
ABRIR ARQUIVOS
  |
OPEN FUNCIONOU?
  |
  +-- NÃO → INFORMAR ERRO E ENCERRAR
  |
  +-- SIM
        |
      LER PRIMEIRO REGISTRO
        |
      FIM DO ARQUIVO?
        |
        +-- SIM → FECHAR ARQUIVOS
        |
        +-- NÃO
              |
           VALIDAR
              |
           PROCESSAR
              |
           GRAVAR
              |
           LER PRÓXIMO
              |
           VOLTAR AO TESTE

Se esse fluxo estiver claro, o código será apenas a tradução da lógica.

O erro mais comum é começar pela sintaxe sem entender o ciclo.

O COBOL não é difícil porque possui palavras em inglês.

Ele se torna difícil quando o programador não sabe qual é o estado do arquivo em cada momento.

Pergunte sempre:

  • o arquivo já foi aberto?

  • o registro atual é válido?

  • o fim do arquivo já foi atingido?

  • a gravação funcionou?

  • os arquivos foram fechados?

  • quantos registros foram lidos?

  • quantos foram gravados?

  • houve rejeições?


20. Arquivo sequencial fixo e variável

Nem todo arquivo sequencial possui registros do mesmo tamanho.

No z/OS, dois formatos muito conhecidos são:

FB — Fixed Blocked

Registros de tamanho fixo.

Exemplo:

LRECL=80

Cada registro possui exatamente 80 bytes.

Se um nome ocupa apenas 20 posições de um campo de 30, as posições restantes normalmente são preenchidas com espaços.

VB — Variable Blocked

Registros de tamanho variável.

Cada registro pode possuir um tamanho diferente, dentro dos limites definidos.

Programadores iniciantes costumam trabalhar primeiro com arquivos fixos porque o layout é mais direto.

Ao receber um arquivo, procure conhecer:

  • RECFM;

  • LRECL;

  • BLKSIZE;

  • codificação;

  • layout;

  • quantidade esperada de registros;

  • origem;

  • destino;

  • critérios de validação.

Um programa pode compilar perfeitamente e ainda assim falhar porque o LRECL não corresponde ao layout.


21. O truque dos buffers

Quando o COBOL executa:

READ EMPLOYEE-FILE

parece que o sistema busca fisicamente apenas aquele registro.

Na prática, o sistema pode usar buffers.

Um bloco contendo vários registros é lido para a memória.

O programa recebe um registro por vez, mas o sistema reduz a quantidade de acessos físicos ao dispositivo.

Esse mecanismo melhora muito o desempenho.

Imagine um arquivo com um milhão de registros.

Buscar cada registro individualmente no dispositivo seria caro.

Ler blocos maiores e entregar os registros gradualmente é muito mais eficiente.

Esse detalhe é quase invisível para o programador, mas explica parte da enorme capacidade de throughput dos ambientes mainframe.


22. Sequencial versus VSAM KSDS

Arthur fez a pergunta inevitável:

— E se eu quiser buscar apenas o funcionário 54321?

O veterano sorriu.

— Então talvez você não queira um arquivo sequencial.

Em um arquivo sequencial, para encontrar um registro localizado no meio do arquivo, o programa normalmente precisa ler os anteriores.

Já um VSAM KSDS utiliza uma chave e uma estrutura indexada.

Pode localizar diretamente um registro específico.

Arquivo sequencial

Ideal para:

  • processamento completo;

  • relatórios;

  • interfaces;

  • cargas;

  • extrações;

  • ordenações;

  • consolidações batch.

VSAM KSDS

Ideal para:

  • acesso por chave;

  • consultas online;

  • atualizações de registros específicos;

  • aplicações CICS;

  • recuperação rápida de dados individuais.

A escolha depende da necessidade.

Não existe tecnologia universalmente superior.

Existe arquitetura adequada ao problema.


23. Erros clássicos de iniciantes

Processar depois do fim do arquivo

Erro:

READ EMPLOYEE-FILE
PERFORM PROCESS-EMPLOYEE

Se o READ encontrou o fim do arquivo, o programa pode processar dados antigos que ainda estão na área do registro.

Forma segura:

READ EMPLOYEE-FILE
    AT END
        SET END-OF-FILE TO TRUE
    NOT AT END
        PERFORM PROCESS-EMPLOYEE
END-READ

Não verificar o OPEN

O programa tenta ler um arquivo que não foi aberto corretamente.

Abrir em modo errado

Abrir como INPUT e tentar gravar.

Esquecer de inicializar o registro de saída

Campos podem carregar conteúdo da gravação anterior.

INITIALIZE REPORT-RECORD

pode ajudar, desde que usado conscientemente.

Não validar campos numéricos

Um campo definido como numérico pode receber conteúdo inválido do arquivo externo.

Antes de calcular:

IF EMP-SALARY IS NUMERIC
    CONTINUE
ELSE
    PERFORM REJECT-RECORD
END-IF

Ignorar contadores

Sem total de entrada e saída, a reconciliação fica muito mais difícil.

Misturar tudo no mesmo parágrafo

Programas tornam-se confusos quando OPEN, READ, cálculo, WRITE e CLOSE são escritos em um único bloco gigantesco.

Separar responsabilidades facilita testes e manutenção.


24. Dicas de sobrevivência no turno da madrugada

Dica 1 — Sempre conheça o layout

Não programe com base em suposições.

Dica 2 — Use FILE STATUS

Especialmente em OPEN, READ e WRITE.

Dica 3 — Conte tudo

Registros lidos, processados, gravados e rejeitados.

Dica 4 — Separe leitura, processamento e escrita

Parágrafos pequenos são mais fáceis de analisar.

Dica 5 — Preserve o registro original quando necessário

Antes de alterar campos de entrada:

MOVE EMPLOYEE-RECORD TO WS-ORIGINAL-RECORD

Dica 6 — Planeje o tratamento de arquivo vazio

Um arquivo vazio pode ser perfeitamente válido.

O primeiro READ retornará fim do arquivo.

Dica 7 — Diferencie erro técnico de erro de negócio

Arquivo inexistente é erro técnico.

Salário negativo pode ser erro de negócio.

Eles exigem tratamentos diferentes.

Dica 8 — Registre mensagens úteis

Evite:

DEU ERRO

Prefira:

ERRO AO ABRIR EMPFILE. FILE STATUS: 35

Quanto melhor a mensagem, menor o tempo de investigação.


25. O exemplo do fechamento bancário

Imagine um banco realizando o fechamento do dia.

Arquivo de entrada:

TRANSACTIONS.DAT

Cada registro contém:

NÚMERO DA TRANSAÇÃO
TIPO
CONTA DE ORIGEM
CONTA DE DESTINO
VALOR
DATA
HORÁRIO

O programa executa:

  1. abre o arquivo de transações;

  2. abre o arquivo de relatório;

  3. abre o arquivo de rejeições;

  4. lê a primeira transação;

  5. valida contas e valores;

  6. classifica a operação;

  7. soma os totais;

  8. grava o resultado;

  9. lê a próxima;

  10. repete até o fim;

  11. fecha todos os arquivos;

  12. mostra os totais de controle.

Ao final:

TRANSAÇÕES LIDAS      : 12.500.000
TRANSAÇÕES PROCESSADAS: 12.499.982
TRANSAÇÕES REJEITADAS : 18
TOTAL PIX             : R$ 987.500.320,18
TOTAL TED             : R$ 145.830.000,00
TOTAL BOLETOS         : R$ 82.114.942,11

Esses números não são apenas informativos.

Eles ajudam a provar que o processamento foi completo e coerente.


26. A analogia com Inteligência Artificial

A comparação com uma IA lendo um documento é interessante.

Imagine um documento com 500 páginas.

A IA precisa:

  1. receber o conteúdo;

  2. interpretar cada parte;

  3. identificar informações relevantes;

  4. manter contexto;

  5. produzir um resumo.

O COBOL faz algo conceitualmente parecido com um arquivo sequencial.

Ele:

  1. abre o arquivo;

  2. lê um registro;

  3. interpreta os campos;

  4. aplica regras;

  5. acumula informações;

  6. grava um resultado;

  7. continua até o fim.

A diferença está no objetivo.

A IA pode produzir uma síntese textual.

O COBOL pode produzir:

  • uma folha de pagamento;

  • um extrato;

  • uma posição contábil;

  • um arquivo fiscal;

  • uma fatura;

  • uma lista de clientes;

  • uma interface para outro sistema.

Nos dois casos, existe um fluxo de entrada, interpretação e saída.


27. Curiosidades do mundo sequencial

A simplicidade é uma vantagem

Sistemas sequenciais possuem poucos estados e um fluxo previsível. Isso facilita auditoria e repetição.

Um arquivo pode alimentar vários programas

Um programa gera o arquivo A.

Outro programa lê A e produz B.

Um terceiro lê B e atualiza um banco de dados.

Essa cadeia forma um fluxo batch.

Arquivos podem ser checkpoints naturais

Em alguns processos, cada etapa gera uma saída persistente. Se a etapa seguinte falhar, não é necessário repetir tudo desde o começo.

SORT é companheiro frequente do COBOL

Muitos arquivos precisam ser classificados antes do processamento.

Um utilitário SORT pode ordenar por conta, data, agência ou código antes de entregar os dados ao programa COBOL.

O conteúdo pode viajar entre plataformas

Arquivos gerados no mainframe podem alimentar sistemas distribuídos, ambientes de analytics, data lakes e APIs.

O conceito é antigo.

A integração continua moderna.


28. Perguntas de entrevista

O que é um arquivo sequencial?

É um arquivo no qual os registros são armazenados e normalmente acessados em ordem, um após o outro.

Quais são as operações básicas?

OPEN
READ
PROCESS
WRITE
CLOSE

Como o programa identifica o fim do arquivo?

Por meio da cláusula AT END, do FILE STATUS ou de ambos, conforme a implementação.

Qual a diferença entre INPUT e OUTPUT?

INPUT abre para leitura.

OUTPUT abre para gravação de um novo conteúdo.

Para que serve EXTEND?

Para acrescentar novos registros ao final de um arquivo.

Por que usar FILE STATUS?

Para verificar o resultado de operações realizadas no arquivo.

O que é um FD?

É a descrição do arquivo na FILE SECTION.

Onde o arquivo físico é definido no z/OS?

Normalmente no JCL, por meio de um DD statement relacionado ao nome usado em ASSIGN TO.

Um arquivo sequencial é adequado para consulta direta por chave?

Geralmente não. Para acesso direto por chave, um formato indexado como VSAM KSDS pode ser mais apropriado.


29. Easter egg: o registro número 1959

Arthur passou horas testando o programa.

Ao final, o arquivo de entrada continha exatamente 1.959 registros.

O número chamou sua atenção.

— Por que 1959? — perguntou.

O veterano olhou para a tela e respondeu:

— Foi o ano em que o CODASYL começou a organizar as bases daquilo que se tornaria o COBOL.

Arthur abriu o último registro.

No campo de observação havia uma mensagem estranha:

READ THE RECORD. TRUST THE STATUS.

Ele riu.

Parecia uma brincadeira deixada por algum programador décadas antes.

Mas o veterano não riu.

— Nunca ignore uma mensagem antiga em produção.

Arthur verificou o FILE STATUS.

10

Fim de arquivo.

Tudo normal.

Ele fechou o dataset e pensou que o mistério havia terminado.

Foi então que percebeu um detalhe.

O contador mostrava:

REGISTROS LIDOS: 000001958

Faltava um.

O programa havia encerrado o loop antes de processar o último registro.

O erro estava na posição da leitura.

A condição de fim era testada no momento errado.

Arthur corrigiu a lógica:

PERFORM READ-EMPLOYEE

PERFORM UNTIL END-OF-FILE
    PERFORM PROCESS-EMPLOYEE
    PERFORM READ-EMPLOYEE
END-PERFORM

Executou novamente.

REGISTROS LIDOS: 000001959

Agora tudo estava certo.

O último registro havia sido processado.

O veterano tomou um gole de café e finalmente sorriu.

— O arquivo nunca mente. O loop, às vezes, sim.


30. O ensinamento final

O processamento sequencial pode parecer simples.

E realmente é.

Mas simplicidade não significa falta de profundidade.

Para dominar arquivos sequenciais, o programador precisa compreender:

  • organização dos dados;

  • layout de registros;

  • relação entre COBOL e JCL;

  • modos de abertura;

  • leitura segura;

  • fim de arquivo;

  • regras de negócio;

  • gravação;

  • FILE STATUS;

  • contadores;

  • rejeições;

  • reconciliação;

  • desempenho;

  • fechamento correto.

Esses princípios aparecem em incontáveis aplicações corporativas.

Quando um banco fecha o movimento do dia, um arquivo sequencial pode estar envolvido.

Quando uma seguradora recalcula milhares de apólices, um arquivo sequencial pode estar envolvido.

Quando o governo processa benefícios, impostos ou registros administrativos, um arquivo sequencial pode estar envolvido.

Quando uma empresa gera a folha de pagamento, novamente ele pode estar lá.

Silencioso.

Disciplinado.

Registro por registro.


Epílogo — O último CLOSE

Já passava das quatro da manhã.

O job terminou com sucesso.

MAXCC=0000

Os arquivos de saída estavam completos.

Os totais conferiam.

Nenhuma transação havia sido perdida.

Arthur fechou o editor, mas permaneceu alguns segundos olhando para a tela.

Agora entendia que o COBOL não era apenas uma linguagem antiga cercada por terminais verdes e histórias de veteranos.

Era uma ferramenta construída para tratar dados com ordem, previsibilidade e responsabilidade.

Antes de ir embora, ele escreveu em seu caderno:

OPEN  — abra a porta com cuidado.
READ  — examine uma evidência por vez.
PROCESS — aplique a lógica sem preconceitos.
WRITE — registre aquilo que foi descoberto.
CLOSE — encerre o caso corretamente.

Do lado de fora, a chuva havia parado.

A cidade começava a acordar.

Milhões de pessoas abririam aplicativos, consultariam saldos, receberiam pagamentos e examinariam extratos sem imaginar que, durante a madrugada, um programa COBOL havia percorrido silenciosamente um enorme arquivo.

Uma linha após a outra.

Um registro após o outro.

Até o fim.

E, como todo bom detetive das antigas, o programa só abandonou o local depois de executar o comando final:

CLOSE EMPLOYEE-FILE
      REPORT-FILE.

STOP RUN.

Caso encerrado.

quinta-feira, 5 de dezembro de 2019

Os Irmãos do Blues do Processamento de Dados Pequena historia dos profissionais de informatica no Brasil

 

Bellacosa Mainframe e a pequena historia do profissional de informatica no Brasil

☕ Um Café no Bellacosa Mainframe

Os Irmãos do Blues do Processamento de Dados

Quando os primeiros profissionais da informática brasileira receberam uma missão: atravessar calculadoras, telégrafos, cartões perfurados, mainframes e cinquenta anos de evolução sem deixar o processamento parar

Era noite.

Em algum lugar do Brasil industrial dos anos 1970, uma impressora de linha martelava milhares de caracteres por minuto. As unidades de fita giravam para frente e para trás como músicos esperando o momento exato de entrar na canção. Luzes piscavam no painel do computador. Um operador carregava um enorme disk pack com as duas mãos, quase como quem transportava um instrumento sagrado.

Do outro lado da parede de vidro, um programador examinava uma listagem contínua coberta de códigos, números de linha e mensagens do compilador.

O programa havia falhado.

Não existia Google.

Não existia Stack Overflow.

Não existia vídeo explicativo.

Não existia inteligência artificial para sugerir a correção.

Existiam apenas o manual, a experiência, o café, a lógica e uma equipe que sabia que precisava colocar aquele sistema novamente em funcionamento antes do amanhecer.

A missão era simples:

fazer o processamento rodar.

O prazo?

Antes que a empresa abrisse as portas.

Os recursos?

Poucos kilobytes de memória, cartões perfurados, fitas magnéticas e uma quantidade quase ilimitada de coragem.

Esta é a história da profissão de informático no Brasil. Uma história que começou muito antes do notebook, do computador pessoal e até mesmo do computador eletrônico. Ela nasceu entre calculadoras mecânicas, máquinas contábeis, telégrafos, ferrovias, fichários e departamentos Hollerith.

É também a história dos perfuradores, conferentes, operadores, programadores, analistas, técnicos de manutenção, administradores de dados e chefes de CPD que transformaram máquinas gigantescas em ferramentas essenciais para o funcionamento do país.

Eles usavam nomes diferentes.

Mas todos faziam parte da mesma banda.


1. Antes do computador, o Brasil já processava dados

Um programador COBOL iniciante pode imaginar que a história da informática começou quando alguém escreveu o primeiro IDENTIFICATION DIVISION.

Não começou.

Muito antes de existirem linguagens de programação, as empresas brasileiras já enfrentavam aquilo que hoje chamaríamos de um problema de escalabilidade.

Imagine uma grande ferrovia.

Ela precisava controlar:

  • milhares de empregados;

  • salários e benefícios;

  • locomotivas;

  • vagões;

  • horários;

  • cargas;

  • passagens;

  • oficinas;

  • ferramentas;

  • peças de reposição;

  • consumo de combustível;

  • manutenção;

  • acidentes;

  • receitas e despesas.

Enquanto uma empresa era pequena, livros contábeis e fichas manuais podiam resolver o problema. Entretanto, quando a organização crescia, o volume de informação tornava o processamento humano lento, caro e sujeito a erros.

O verdadeiro antepassado do profissional de informática não foi apenas o matemático.

Foi também o escriturário.

Era ele quem registrava, classificava, somava, conferia e arquivava informações. Em enormes salas administrativas, dezenas ou centenas de pessoas processavam dados manualmente.

O computador não surgiu primeiro para criar imagens, músicas ou mundos virtuais.

Ele surgiu para vencer filas de documentos.


2. Calculadoras mecânicas: a pré-história do processamento

Antes do computador eletrônico, existiram calculadoras mecânicas e eletromecânicas.

Elas realizavam somas, subtrações e, dependendo do modelo, multiplicações e divisões. Algumas funcionavam por manivelas. Outras utilizavam motores elétricos para movimentar engrenagens, rodas e registradores.

Não eram computadores de propósito geral, mas já introduziam uma ideia revolucionária:

Uma parte do trabalho intelectual poderia ser automatizada por uma máquina.

Para um jovem acostumado com processadores executando bilhões de operações por segundo, pode parecer pouco.

Mas considere o contexto.

Uma folha de pagamento com milhares de funcionários exigia inúmeros cálculos. Um erro poderia significar salário incorreto, imposto indevido ou total contábil incompatível.

A calculadora mecânica diminuía o esforço, mas ainda dependia intensamente do operador.

A pessoa digitava os valores.

A máquina calculava.

A pessoa anotava o resultado.

A informação precisava ser transportada manualmente de um documento para outro.

Era uma arquitetura com alto acoplamento humano.

O usuário funcionava como CPU, memória, barramento e interface.


3. O telégrafo e a primeira rede brasileira

Enquanto máquinas contábeis processavam números, o telégrafo conectava cidades, estações ferroviárias, portos e centros administrativos.

Ele foi uma das primeiras grandes infraestruturas de comunicação de dados.

Sim, caro padawan do COBOL: o telégrafo pode ser entendido como um ancestral distante das redes de computadores.

Uma mensagem era codificada.

Transmitida por um meio físico.

Recebida em outro ponto.

Decodificada.

Confirmada ou retransmitida.

Temos aí vários elementos conhecidos:

  • origem;

  • destino;

  • protocolo;

  • codificação;

  • transmissão;

  • recepção;

  • tratamento de erro;

  • operador.

Quando um telegrafista enviava uma mensagem para organizar a circulação de trens, ele participava de um sistema distribuído.

A diferença é que o middleware usava Código Morse e o operador humano fazia aquilo que hoje seria responsabilidade de um software de comunicação.

A ferrovia, portanto, não transportava apenas pessoas e mercadorias.

Transportava informações.


4. O Departamento Hollerith da Companhia Paulista

É nesse mundo de ferrovias, telégrafos, escrituração e mecanização administrativa que encontramos os departamentos Hollerith.

O nome vinha de Herman Hollerith, criador de sistemas de processamento baseados em cartões perfurados. Sua tecnologia ficou famosa pela utilização no censo norte-americano de 1890 e tornou-se a base de uma indústria de máquinas de tabulação.

No Brasil, grandes organizações passaram a empregar máquinas Hollerith para atividades administrativas. A Companhia Paulista de Estradas de Ferro está ligada a essa história de mecanização do processamento de informações ferroviárias.

O Departamento Hollerith era uma espécie de antepassado do CPD.

Não havia processador eletrônico central.

Havia um conjunto de máquinas especializadas.

Uma perfurava.

Outra conferia.

Outra classificava.

Outra intercalava.

Outra tabulava.

Outra imprimia.

O processamento era realizado como uma linha de montagem.

Observe como isso se aproxima de um pipeline:

Documento de origem
        ↓
Codificação dos dados
        ↓
Perfuração
        ↓
Conferência
        ↓
Classificação
        ↓
Tabulação
        ↓
Relatório

Hoje podemos substituir essas etapas por:

Formulário digital
        ↓
Validação
        ↓
API
        ↓
Fila
        ↓
Processamento
        ↓
Banco de dados
        ↓
Dashboard

A aparência mudou.

A lógica permaneceu.


5. O cartão perfurado: o banco de dados que cabia na mão

O cartão perfurado de 80 colunas tornou-se um dos maiores símbolos da informática corporativa.

Cada posição podia ser perfurada de acordo com um código. Letras, números e símbolos eram representados por combinações de furos.

Para um programador moderno, podemos imaginar um cartão como um registro físico.

Se o cartão representasse um funcionário, suas colunas poderiam ser organizadas assim:

01-06  Matrícula
07-36  Nome
37-44  Data de admissão
45-54  Salário
55-56  Código do departamento
57-80  Informações complementares

Isso é um arquivo de largura fixa.

Quem trabalha com COBOL reconhecerá imediatamente a filosofia.

01 REGISTRO-FUNCIONARIO.
   05 MATRICULA             PIC 9(06).
   05 NOME                  PIC X(30).
   05 DATA-ADMISSAO         PIC 9(08).
   05 SALARIO               PIC 9(08)V99.
   05 COD-DEPARTAMENTO      PIC 9(02).
   05 COMPLEMENTO           PIC X(24).

O cartão perfurado não era apenas mídia.

Ele também influenciou a própria estrutura das linguagens e dos programas.

O formato tradicional do COBOL foi organizado considerando cartões de 80 colunas:

  • colunas 1 a 6: sequência;

  • coluna 7: indicador;

  • colunas 8 a 11: Área A;

  • colunas 12 a 72: Área B;

  • colunas 73 a 80: identificação.

Nada disso nasceu por acaso.

O formato fixo do COBOL é uma lembrança fossilizada do cartão perfurado.

Easter egg desbloqueado: sempre que você encontra um programa COBOL antigo usando colunas rígidas, está olhando para a sombra digital de uma máquina de perfuração.


6. A perfuradora não era uma simples digitadora

Uma das profissões fundamentais daquela época era a de perfurador ou perfuradora.

O programador escrevia o código em folhas de codificação.

Essas folhas eram encaminhadas ao setor de perfuração.

O profissional lia cada linha e a transferia para cartões.

A operação exigia velocidade, atenção e precisão.

Um furo errado poderia transformar:

ADD VALOR-VENDA TO TOTAL-VENDAS

em uma instrução inválida.

Pior: dependendo do erro, o programa poderia ser compilado e produzir um resultado incorreto.

Depois da perfuração vinha a conferência.

Em muitas instalações, outro profissional digitava novamente o conteúdo em uma máquina verificadora. Se a sequência digitada não correspondesse aos furos existentes, a máquina indicava divergência.

Era uma forma humana e mecânica de dupla validação.

Hoje chamamos isso de controle de qualidade.

Naquela época, chamava-se sobrevivência operacional.


7. Quando deixar cair um programa era literalmente possível

Um programa podia ser formado por centenas ou milhares de cartões.

Cada cartão representava uma linha.

Os cartões precisavam permanecer em ordem.

Se a pilha caísse no chão, o programa também caía.

Literalmente.

Por isso as colunas iniciais frequentemente continham números de sequência.

Caso o desastre acontecesse, os cartões poderiam ser classificados novamente por uma máquina sorter.

Essa é uma bela lição para o programador iniciante:

Numeração de sequência não era decoração. Era recuperação de desastre.

Hoje você usa Git.

Naquela época, usava-se disciplina, numeração e caixas de cartão.

A frase “meu código quebrou” tinha outra dimensão.


8. Os primeiros computadores desembarcam no Brasil

A chegada dos computadores eletrônicos ao Brasil ocorreu durante a década de 1950.

Um marco frequentemente citado é a instalação, em 1957, de um computador Univac para o governo do Estado de São Paulo. Pouco depois, em 1959, a Anderson Clayton adquiriu um IBM 305 RAMAC, apontado como o primeiro computador eletrônico instalado no setor privado brasileiro. (Din UEM)

O RAMAC era impressionante porque utilizava armazenamento em disco de acesso aleatório. Sua unidade IBM 350 empregava cinquenta discos magnéticos de grandes dimensões e armazenava poucos megabytes — capacidade minúscula hoje, mas revolucionária naquele contexto. (Wikipédia)

Não pense nesses computadores como PCs enormes.

Eles pertenciam a outro universo operacional.

A empresa não “comprava um computador” como quem compra uma estação de trabalho.

Ela implantava uma infraestrutura.

Era necessário preparar:

  • sala especial;

  • alimentação elétrica;

  • climatização;

  • piso;

  • cabeamento;

  • procedimentos;

  • operadores;

  • técnicos;

  • programadores;

  • métodos de segurança;

  • rotinas de backup.

A chegada do computador criava um novo departamento e uma nova cultura.


9. O CPD entra no palco

O Centro de Processamento de Dados, o famoso CPD, tornou-se o coração informacional das organizações.

Ali ficavam:

  • a unidade central;

  • leitoras de cartões;

  • perfuradoras;

  • impressoras de linha;

  • unidades de fita;

  • discos removíveis;

  • consoles;

  • painéis;

  • formulários contínuos;

  • armários de documentação.

O CPD era cercado por respeito e mistério.

Possuía acesso controlado.

Em muitos ambientes havia paredes de vidro separando os visitantes das máquinas.

O ar-condicionado era intenso.

Os operadores usavam roupas adequadas ao ambiente e, em algumas empresas, jalecos.

As máquinas produziam uma trilha sonora própria:

clac-clac-clac dos cartões,

vrummm das fitas,

trrrrrrrrr das impressoras,

bip do console.

Era rhythm and blues em código binário.

Uma banda inteira tocando para fechar a folha de pagamento.


10. IBM System/360: a grande banda entra em cena

Em 1964, a IBM anunciou a família System/360.

O nome representava a ambição de cobrir uma ampla variedade de aplicações: negócios, ciência, indústria e governo.

O conceito de família compatível foi revolucionário.

Antes disso, migrar para uma máquina maior frequentemente exigia reescrever programas. Com o System/360, a IBM buscava permitir que clientes evoluíssem dentro de uma arquitetura comum.

No Brasil, sistemas dessa família chegaram a bancos, indústrias, siderúrgicas, universidades e órgãos públicos.

Para empresas como a Mannesmann, o mainframe tornou-se parte da infraestrutura industrial.

Ele processava:

  • produção;

  • estoques;

  • custos;

  • materiais;

  • compras;

  • folha de pagamento;

  • contabilidade;

  • faturamento;

  • manutenção.

O computador deixava de ser uma curiosidade tecnológica.

Tornava-se sistema nervoso corporativo.


11. Uma carteira de trabalho assinada em 1975

Quando alguém olha para uma carteira de trabalho assinada em 1975 com uma função relacionada a processamento de dados, não está vendo apenas um registro profissional.

Está vendo um documento arqueológico da informática brasileira.

A pessoa que ingressava em um CPD naquela época encontrava um mundo sem interfaces amigáveis.

Aprender significava:

  1. observar profissionais experientes;

  2. estudar manuais;

  3. decorar códigos;

  4. entender formulários;

  5. acompanhar operações;

  6. interpretar mensagens;

  7. registrar procedimentos;

  8. errar com cuidado;

  9. nunca repetir o mesmo erro;

  10. respeitar a produção.

No CPD da Mannesmann, diante de um IBM System/360, as limitações de memória não eram uma abstração acadêmica.

Eram parte de cada decisão.

Uma tabela muito grande podia não caber.

Um programa mal estruturado podia consumir recursos preciosos.

Um excesso de operações de entrada e saída podia aumentar o tempo de execução.

Um erro na definição de arquivo podia interromper toda uma cadeia de processamento.

Essa escola criava um tipo específico de profissional:

alguém que pensava antes de executar.


12. O programador não começava programando

O caminho profissional podia começar em várias funções:

Auxiliar administrativo
        ↓
Perfurador
        ↓
Conferente
        ↓
Operador
        ↓
Programador trainee
        ↓
Programador júnior
        ↓
Programador pleno
        ↓
Programador sênior
        ↓
Analista de sistemas

Nem todas as carreiras seguiam exatamente essa ordem, mas era comum o conhecimento ser adquirido dentro da empresa.

O profissional conhecia primeiro a operação.

Depois aprendia a lógica.

Depois recebia pequenas alterações.

Mais tarde criava programas completos.

Isso tinha uma vantagem enorme: muitos programadores entendiam profundamente como o sistema era executado.

Eles sabiam o que acontecia antes e depois de seu código.

Sabiam quem montava a fita.

Sabiam onde o relatório era entregue.

Sabiam qual departamento dependia do processamento.

Hoje um desenvolvedor pode executar uma aplicação sem conhecer a infraestrutura.

Naquela época, software e operação viviam quase grudados.

Era DevOps antes do nome DevOps.


13. A folha de codificação: programar antes de digitar

O programa começava no papel.

O analista descrevia o problema.

Criava fluxogramas.

Definia arquivos.

Desenhava relatórios.

Especificava validações.

O programador recebia essas informações e escrevia o código em folhas de codificação.

Cada linha era planejada.

Depois a folha seguia para perfuração.

Esse processo podia levar horas ou dias até a primeira compilação.

Portanto, escrever código sem pensar era muito caro.

Considere um ciclo típico:

Especificação
     ↓
Fluxograma
     ↓
Teste de mesa
     ↓
Folha de codificação
     ↓
Perfuração
     ↓
Conferência
     ↓
Montagem do deck
     ↓
Submissão
     ↓
Compilação
     ↓
Listagem
     ↓
Correção

Hoje o compilador responde em segundos.

Naquela época, o programador podia entregar o job e aguardar uma janela de processamento.

O erro voltava impresso.

A depuração era feita examinando papel.


14. O teste de mesa: o debugger dentro da cabeça

Antes de submeter o programa, o profissional realizava o teste de mesa.

Ele simulava manualmente a execução.

Suponha o seguinte trecho:

MOVE 0 TO TOTAL-GERAL

PERFORM UNTIL FIM-ARQUIVO = 'S'
    READ ARQUIVO-VENDAS
        AT END
            MOVE 'S' TO FIM-ARQUIVO
        NOT AT END
            ADD VALOR-VENDA TO TOTAL-GERAL
    END-READ
END-PERFORM

No teste de mesa, o programador criava uma pequena tabela:

Registro   Valor   Fim?   Total
1          100     N      100
2          250     N      350
3           50     N      400
EOF        ---     S      400

Ele verificava cada mudança de variável.

Isso revelava loops infinitos, totais incorretos, condições erradas e registros processados duas vezes.

Dica Bellacosa para o iniciante:

Quando um programa COBOL parecer misterioso, execute cinco registros no papel. O papel não mente e não esconde estado.


15. O operador: maestro da sala de máquinas

O operador não era alguém que apenas apertava ENTER.

Ele controlava a execução física e lógica do ambiente.

Suas tarefas podiam incluir:

  • iniciar equipamentos;

  • carregar o sistema;

  • montar fitas;

  • instalar disk packs;

  • alimentar leitoras;

  • retirar listagens;

  • controlar filas;

  • responder a mensagens;

  • registrar falhas;

  • reiniciar jobs;

  • comunicar incidentes;

  • executar rotinas de backup.

Imagine um job solicitando:

MOUNT TAPE PAYR01 ON UNIT 480

Alguém precisava localizar a fita correta, conferir sua etiqueta, montá-la na unidade e responder ao sistema.

A automação dependia de mãos humanas.

O operador era parte do fluxo de execução.

Se ele montasse a fita errada, o sistema poderia ler informações incorretas.

Por isso existiam procedimentos rigorosos.

O CPD ensinou cedo uma lição que a nuvem às vezes faz esquecer:

Infraestrutura abstrata continua sendo infraestrutura real em algum lugar.


16. Disk packs: o disco removível com peso de responsabilidade

Antes dos pequenos discos rígidos modernos, eram comuns conjuntos removíveis de discos magnéticos.

Os disk packs possuíam múltiplos pratos.

O operador os transportava em recipientes protetores e os instalava em unidades específicas.

Cada superfície podia armazenar dados.

Uma poeira, um impacto ou uma instalação inadequada podia causar danos.

A troca de um volume não era um clique.

Era uma operação física.

Hoje montamos um volume em cloud computing usando uma instrução ou console.

Naquela época, “montar o volume” significava literalmente pegar o volume com as mãos.

Outro easter egg tecnológico:

O verbo mount, usado até hoje em sistemas operacionais, preserva a memória de uma época em que mídias precisavam ser fisicamente montadas.


17. Fitas magnéticas e o pensamento sequencial

As fitas magnéticas foram fundamentais.

Elas ofereciam boa capacidade para a época e eram úteis para:

  • arquivos históricos;

  • backups;

  • processamento em lote;

  • transferência;

  • entrada e saída de grandes volumes.

Mas a fita era sequencial.

Para chegar ao registro desejado, era necessário percorrer os anteriores.

Esse comportamento influenciou profundamente os programas COBOL.

Muitos sistemas eram desenhados para ler dois arquivos ordenados e realizar casamento de registros.

Exemplo:

Arquivo de clientes
+ 
Arquivo de pagamentos
=
Relatório de clientes pagos e inadimplentes

O algoritmo caminhava pelos dois arquivos em ordem de chave.

Essa técnica continua valiosa.

Ela ensina que a melhor solução depende das características do armazenamento.

Não existe algoritmo isolado da infraestrutura.


18. O analista de sistemas: tradutor entre dois mundos

Com o crescimento dos sistemas, tornou-se necessário separar responsabilidades.

O analista conversava com as áreas de negócio.

Ele precisava compreender:

  • como a empresa funcionava;

  • quais documentos existiam;

  • quais regras eram aplicadas;

  • onde ocorriam erros;

  • quais relatórios eram necessários;

  • quais arquivos deveriam ser criados;

  • quais controles seriam obrigatórios.

Depois transformava isso em especificação técnica.

O analista era um tradutor.

De um lado, o usuário dizia:

“Preciso impedir o faturamento de clientes bloqueados.”

Do outro, o programador precisava receber algo como:

Se o código de situação do cliente for diferente de 01,
rejeitar a transação, registrar ocorrência e emitir mensagem 145.

Boa análise elimina ambiguidade.

Esse princípio continua absolutamente atual.

Um requisito ruim em 1975 gerava um programa errado.

Um requisito ruim em 2026 gera um microsserviço errado muito mais rapidamente.


19. Os primeiros cursos e a formação prática

Durante os primeiros anos, a indústria formava grande parte de seus profissionais.

Fabricantes ofereciam treinamento.

Empresas criavam programas internos.

Manuais técnicos circulavam entre equipes.

Os primeiros cursos superiores brasileiros voltados especificamente à computação surgiram no final da década de 1960. Estudos históricos apontam a criação, em 1969, de cursos de graduação plena na Unicamp e na Universidade Federal da Bahia. (HCTE UFRJ)

Até que essa formação se difundisse, os profissionais pioneiros precisavam vir de outras áreas:

  • engenharia;

  • matemática;

  • administração;

  • contabilidade;

  • estatística;

  • operação de máquinas;

  • funções administrativas.

A informática brasileira foi construída por uma tripulação heterogênea.

Não havia uma estrada pronta.

Eles desenharam a estrada enquanto dirigiam.


20. Uma correção histórica importante sobre 1985

Aqui precisamos ajustar uma informação frequentemente repetida.

O Decreto nº 91.250, de 17 de maio de 1985, não regulamentou de forma ampla e definitiva o exercício das profissões de informática no setor privado brasileiro.

Ele alterou dispositivos do Decreto nº 83.989, de 1979, relacionados a categorias funcionais e requisitos de ingresso no serviço público federal. Entre as alterações, incluiu o curso de Tecnólogo em Processamento de Dados entre as formações aceitas para a categoria funcional de Analista de Sistemas. (Presidência da República)

Portanto, a interpretação mais precisa é:

O decreto contribuiu para organizar e reconhecer cargos de informática dentro da estrutura funcional federal, mas não criou uma regulamentação geral da profissão de programador ou analista para todo o mercado brasileiro.

A regulamentação ampla das profissões de informática continuou sendo objeto de debates e projetos legislativos posteriores. (Legis Senador)

Isso não diminui a importância histórica de 1985.

Pelo contrário.

Mostra como o Estado precisou adaptar suas estruturas administrativas ao crescimento de uma atividade que já existia havia décadas.

A profissão surgiu primeiro.

A legislação tentou alcançá-la depois.


21. O veterano sem diploma específico não era improvisado

Quando se fala em reconhecer experiência profissional, é preciso evitar um erro comum.

O pioneiro que não possuía diploma de Ciência da Computação não era necessariamente alguém sem formação.

Muitos eram engenheiros, matemáticos, administradores, contadores ou técnicos altamente especializados.

Outros haviam aprendido integralmente dentro das empresas.

Eles acumulavam milhares de horas de prática.

Conheciam máquinas que exigiam domínio simultâneo de:

  • lógica;

  • hardware;

  • armazenamento;

  • operação;

  • linguagem;

  • negócio;

  • contingência;

  • documentação.

O mercado não podia simplesmente declarar:

“Agora existe um curso; tudo o que veio antes deixou de valer.”

Seria como construir uma ponte e depois informar aos engenheiros que fizeram a obra que sua experiência não conta.

O reconhecimento da experiência preservava a memória técnica das organizações.


22. A reserva de mercado e a informática nacional

Durante parte das décadas de 1970 e 1980, o Brasil adotou políticas de proteção à indústria nacional de informática.

A intenção era reduzir dependência externa e desenvolver capacidade tecnológica local.

Esse movimento ajudou a estimular empresas, pesquisas e projetos nacionais, mas também limitou o acesso a certos equipamentos estrangeiros, aumentou custos e criou diferenças tecnológicas em relação aos principais mercados mundiais.

Foi uma história cheia de contradições.

De um lado:

  • formação de engenheiros;

  • criação de empresas nacionais;

  • desenvolvimento de hardware;

  • pesquisa universitária;

  • domínio local de tecnologias.

Do outro:

  • equipamentos caros;

  • atraso em determinados segmentos;

  • restrições de importação;

  • compatibilidades problemáticas;

  • mercado paralelo.

Em 1972, o Patinho Feio, desenvolvido na Universidade de São Paulo, tornou-se um símbolo do esforço brasileiro de projetar computadores. O projeto nasceu no ambiente acadêmico da Escola Politécnica da USP e deixou um legado importante para ensino e indústria. (Revista Pesquisa Fapesp)

A informática nacional não foi apenas uma tentativa de copiar máquinas.

Foi também um laboratório de formação humana.


23. A grande migração: do cartão para o terminal

Com a popularização dos terminais, especialmente famílias como o IBM 3270, a relação entre o programador e o computador mudou.

Antes:

Papel → perfuração → cartão → leitora → compilação → listagem

Depois:

Terminal → editor → submissão → spool → correção

O ciclo encurtou.

Ferramentas como TSO e ISPF transformaram o desenvolvimento em mainframe.

O código passou a ser editado diretamente em datasets.

O programador podia consultar a saída no spool.

Alterar uma linha tornou-se muito mais rápido.

Mas os hábitos do cartão continuaram presentes:

  • colunas;

  • largura fixa;

  • sequência;

  • datasets;

  • jobs;

  • relatórios;

  • processamento batch.

A nova tecnologia não apagou a anterior.

Construiu sobre ela.


24. Cinquenta anos de armazenamento

Uma pessoa que iniciou a carreira em 1975 pôde testemunhar uma das maiores transformações materiais da história.

Ela atravessou:

Cartão perfurado
      ↓
Fita magnética
      ↓
Disk pack
      ↓
Disquete
      ↓
Disco rígido
      ↓
RAID
      ↓
Storage corporativo
      ↓
SAN
      ↓
SSD
      ↓
NVMe
      ↓
Object storage
      ↓
Cloud computing

No cartão, o dado era visível como um furo.

Na fita, era uma sequência magnética.

No disco, ocupava trilhas e setores.

Na nuvem, parece não possuir localização física.

Mas ainda está armazenado em algum dispositivo.

A nuvem não eliminou o hardware.

Apenas colocou o hardware atrás de uma API.


25. O que o programador COBOL iniciante deve aprender com os pioneiros

Passo 1 — Entenda o negócio

Não comece apenas pela sintaxe.

Descubra:

  • quem usa o programa;

  • qual processo ele atende;

  • quais dados recebe;

  • qual resultado produz;

  • o que acontece quando falha.

Passo 2 — Leia o layout do arquivo

Em COBOL, dados são arquitetura.

Analise:

  • PIC;

  • tamanho;

  • sinal;

  • casas decimais;

  • campos redefinidos;

  • níveis;

  • campos de controle.

Passo 3 — Faça um teste de mesa

Pegue poucos registros.

Simule:

  • entrada;

  • condições;

  • cálculos;

  • saída;

  • fim de arquivo.

Passo 4 — Conheça o JCL

O programa não vive sozinho.

O JCL informa:

  • qual programa executar;

  • quais arquivos utilizar;

  • onde estão os dados;

  • o que fazer com a saída;

  • quais recursos serão necessários.

Passo 5 — Leia o spool

Não procure apenas a última mensagem.

Examine:

  • etapas executadas;

  • códigos de retorno;

  • mensagens;

  • alocações;

  • estatísticas;

  • dumps.

Passo 6 — Respeite a produção

Nunca trate uma alteração como “apenas uma linha”.

Uma linha pode afetar:

  • milhões de registros;

  • milhares de clientes;

  • fechamento contábil;

  • pagamento;

  • faturamento;

  • obrigação legal.

Passo 7 — Documente

O profissional seguinte talvez seja você mesmo seis meses depois.

Escreva para que ele entenda.


26. Curiosidades da estrada mainframe

O formulário contínuo tinha personalidade

Impressoras de linha utilizavam papel contínuo com furos laterais. Relatórios gigantes podiam ocupar caixas inteiras.

O erro podia chegar de carrinho

Listagens volumosas eram transportadas em carrinhos dentro de grandes CPDs.

O som ajudava no diagnóstico

Operadores experientes reconheciam anormalidades pelo ruído das unidades e impressoras.

A mídia tinha biblioteca

Fitas e discos eram armazenados, catalogados, emprestados e devolvidos como livros.

Backup era uma operação física

Copiar dados significava usar dispositivos, mídias, tempo de máquina e procedimentos formais.

O café era um componente crítico

Não aparece no diagrama da arquitetura, mas sustentou muitas janelas batch.


27. Easter egg: estamos em uma missão de Deus?

Os protagonistas de uma famosa comédia musical de 1980 cruzam estradas, reúnem antigos companheiros e enfrentam obstáculos absurdos para salvar aquilo em que acreditam.

A geração pioneira da informática brasileira também recebeu uma missão.

Não usava um automóvel preto atravessando Chicago.

Usava ônibus, trem, fusca, crachá e relógio de ponto.

Não precisava reunir uma banda.

Precisava reunir:

  • o analista;

  • o programador;

  • o perfurador;

  • o conferente;

  • o operador;

  • o técnico;

  • o usuário;

  • o chefe do CPD.

Quando todos trabalhavam em harmonia, o processamento entrava no ritmo.

Quando um deles saía do compasso, aparecia o ABEND.

A diferença entre uma banda e um CPD talvez seja menor do que parece.

Ambos exigem sincronização.

Ambos dependem de disciplina.

Ambos possuem bastidores invisíveis.

E ambos podem ser destruídos por alguém que entra no momento errado.


28. O verdadeiro mainframe sempre foi humano

É tentador contar a história da informática como uma sequência de máquinas.

Hollerith.

UNIVAC.

RAMAC.

System/360.

System/370.

308X.

ES/9000.

S/390.

IBM Z.

Mas máquinas não escrevem sua própria história.

Foram pessoas que decidiram como utilizá-las.

Pessoas perfuraram cartões.

Pessoas carregaram discos.

Pessoas interpretaram dumps.

Pessoas enfrentaram madrugadas.

Pessoas explicaram sistemas.

Pessoas ensinaram colegas.

Pessoas preservaram programas.

Pessoas migraram dados.

Pessoas impediram que décadas de conhecimento fossem perdidas.

O profissional que começou em 1975 e chegou à computação em nuvem não atravessou apenas mudanças de equipamento.

Atravessou diferentes maneiras de imaginar o que é informação.

Primeiro, a informação era um documento.

Depois, um furo.

Depois, um campo magnético.

Depois, um registro.

Depois, uma tabela.

Depois, um objeto.

Depois, um evento distribuído.

Mas, em todas as épocas, alguém precisou responder às mesmas perguntas:

  • O dado está correto?

  • O processamento terminou?

  • O resultado pode ser confiado?

  • Existe recuperação?

  • Quem será afetado?

  • O que faremos se falhar?


Conclusão: todos fazem parte da mesma banda

A história da profissão de informático no Brasil não começa no Vale do Silício.

Começa também nas ferrovias, nos escritórios, nos bancos, nas siderúrgicas, nas repartições públicas, nas universidades e nos departamentos Hollerith.

Começa com pessoas que mecanizaram cálculos.

Continua com perfuradores que transformaram papel em dados.

Avança com operadores que comandaram salas cheias de máquinas.

Ganha lógica com programadores que escreveram sistemas em Assembler, COBOL, FORTRAN e RPG.

Ganha visão com analistas que converteram processos empresariais em especificações.

Ganha escala com os grandes mainframes.

Ganha alcance com redes e terminais.

Ganha velocidade com discos e servidores.

Ganha abstração com virtualização e nuvem.

E chega ao presente com ambientes distribuídos, inteligência artificial e armazenamento aparentemente infinito.

Entretanto, a essência permanece.

Informática continua sendo a arte de transformar uma necessidade humana em uma sequência confiável de operações.

Por isso, olhar para uma carteira de trabalho assinada em 1975 não é praticar nostalgia vazia.

É reconhecer um documento de fundação.

Aquela assinatura pertence a uma geração que entrou em CPDs quando o conhecimento ainda precisava ser descoberto, traduzido e transmitido de pessoa para pessoa.

Uma geração que programava na raça.

Que respeitava cada byte.

Que sabia o peso de um disco.

Que conhecia o valor de uma fita.

Que entendia o silêncio de uma máquina parada.

Que não precisava chamar tudo de “missão crítica”, porque sabia que, se o processamento não terminasse, alguém não receberia, uma fábrica não faturaria ou um banco não fecharia.

A nova geração precisa conhecer essa história não para repetir suas limitações, mas para herdar suas virtudes:

disciplina,

curiosidade,

responsabilidade,

capacidade de análise,

respeito aos dados,

e coragem para enfrentar sistemas que parecem impossíveis.

Portanto, coloque os óculos escuros.

Ajuste o chapéu.

Confira o JCL.

Monte a fita.

Não derrube os cartões.

Temos memória limitada, uma janela batch fechando, centenas de quilômetros de história pela frente e um sistema inteiro esperando para ser processado.

Estamos em uma missão.

Fazer o conhecimento dos pioneiros continuar rodando.

Conheça um pouco sobre o Cobol

 https://eljefemidnightlunch.blogspot.com/2009/04/cobol-uma-odisseia-de-1959-ao-ibm-z.html

terça-feira, 3 de dezembro de 2019

🔥 PUDDING JAPONÊS — O “flan supremo” dos animes,



🔥 PUDDING JAPONÊS — O “flan supremo” dos animes, explicado ao estilo Bellacosa Mainframe para o blog El Jefe Midnight Lunch 🔥
(em primeira pessoa, porque memória boa a gente serve quentinha)


Sabe quando você está maratonando anime — aquele slice of life gostosinho, ou mesmo um shounen pancadaria — e do nada aparece um potinho transparente com um flan tremelicando perigosamente? Aquele dourado brilhante, coberto por uma caldinha marrom que parece ter 99% de açúcar e 1% de magia? Pois é, meus otakus padawans… aquilo é o lendário Pudding Japonês.

Ou, como dizem por lá: プリン (Purin).
Sim, “purin” — porque o Japão tem o superpoder de pegar palavras ocidentais e transformá-las em fofura.




🥮 O QUE DIABOS É O PURIN?

Pensa no nosso pudim brasileiro?
Pois tire o leite condensado, tire o furo no meio, reduza 50% da alma brasileira e adicione:

  • consistência mais firme, porém tremelicante;

  • muito ovo (mas com sabor suave);

  • calda de caramelo mais líquida;

  • formato individual;

  • e aquele brilho que parece que ele foi renderizado com Ray Tracing.

Ele está mais para uma fusão entre flan francês + geleia firme + magia das obachan.


🧪 ORIGEM — ou como o Japão fez do pudim um evento cultural

O purin chegou ao Japão no período Meiji (lá por 1870), quando o país abriu as portas para as influências ocidentais. Os japoneses, meticulosos como bons “engenheiros do sabor”, ajustaram a receita para ficar:

  • mais suave,

  • mais firme,

  • mais fácil de industrializar,

  • e perfeita para aparecer em 10.000 animes por ano.

Nas décadas de 1950–60, com o boom dos konbini (lojinhas de conveniência), ele se tornou o lanche portátil número 1. Assim como o cartão perfurado no mainframe, o pudim virou onipresente.


📺 PUDDING NOS ANIMES — onde ele brilhou

Esse glorioso flan animado é praticamente um NPC recorrente do Japão. Alguns momentos clássicos:

🍮 Purin do Shin-Chan

Shin-chan vive roubando o pudim do pai. Clássico supremo da cultura otaku.

🍮 Purin no Pokémon

Jigglypuff é chamado de Purin no original (isso mesmo!).
O nome é literalmente “PU-DIM”.
Coincidência? Eu acho é que o bicho foi modelado num flan 3D.

🍮 Sailor Moon

Usagi, sempre faminta, devorava purin como se fosse XP.

🍮 Anya de Spy x Family

Só falta fazer contrato JCL pra garantir o estoque de pudim daquela criança.
Purin é praticamente moeda de troca emocional da Anya.

🍮 Cardcaptor Sakura

Tomoyo sempre aparecia com lanches sofisticados. Claro que o pudim desfilava lá no meio.

🍮 Animes escolares

Em 99,99% deles, sempre tem:

  • o pudim do konbini,

  • o pudim caseiro da mãe amorosa,

  • ou o pudim roubado pelo protagonista bobão.


🧐 CURIOSIDADES, BUGS E EASTER EGGS OTÁKICOS

💡 1. O purin aparece como símbolo de “doçura infantil”
Se o anime quer mostrar inocência, conforto ou algo “fofinho”, prepara que o pudim vem.

💡 2. Existe “Purin Gigante”
No Japão tem versões MONSTRUOSAS, do tamanho de um volume 327 do manual do RACF.
Anime que é anime sempre mostra um desses.

💡 3. O purin virou meme de “item de cura”
Em jogos e animes, comer purin recupera energia.
Se fosse no mainframe, recuperaria MIPS.

💡 4. Purin é usado como punição
Sabe quando alguém come o pudim do outro da geladeira?
No Japão isso é TRETA nível CICS degradando recurso.
É sério. Rola briga familiar por causa disso.

💡 5. Tem purin “premium premium”
Feitos com ovos especiais, leite Hokkaido, calda artesanal…
O Japão conseguiu transformar pudim em artigo de luxo.


🍮 COMO SABOREAR COMO UM VERDADEIRO OTAKU

✔ Coma geladinho, de colherinha pequena
✔ Comece pela borda para soltar aquela tremidinha hipnotizante
✔ Não misture tudo — é pecado
✔ Se der pra comer no konbini, sentado na calçada… XP aumenta +10


🔧 DICAS BELLACOSA MAINFRAME

Se pudim fosse job JCL seria:

//PUDIM EXEC FLANPROC //OVOS DD DISP=SHR //ACUCAR DD DISP=SHR //LEITE DD DISP=SHR //TEMPO DD DLY=’00:45’ //SAIDA DD SYSOUT=P

E sempre teria um abend chamado:
S0P1 – Someone ate your pudding before you.


❤️ FECHANDO O POST — MEMÓRIA AFETIVA MODE ON

Eu sempre falo que comida boa vira checkpoint da vida.
E o purin japonês virou, para nós otakus, aquele dump de memória afetiva que aparece do nada e traz um sorriso instantâneo.

Toda vez que vejo um potinho tremendo num anime, lembro que:

  • a vida precisa de doçura,

  • de pausas

  • e de pequenos prazeres simples…

…até porque não dá pra viver só de manuais de 300 páginas, CICS, JCL e dumps infernais.

Às vezes, tudo que a gente precisa é um purin geladinho na noite de sábado, como nos velhos animes da juventude.


segunda-feira, 2 de dezembro de 2019

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

 

Bellacosa Mainframe e o call em cobol parte xii

☕💥 A Jornada do Padawan COBOL – Parte 12

Desvendando o Universo dos CALLs no Mainframe

PSA, CVT, ASCB, TCB, RB, ACEE, CSA, ECSA, LSQA, SQA e os Mistérios dos Control Blocks que Sustentam o z/OS

Ou como descobrir que existe um universo inteiro escondido em endereços hexadecimais que praticamente nenhum desenvolvedor COBOL vê

Por Vagner Bellacosa – Bellacosa Mainframe


O Dia em que o Padawan Descobre o Lado Oculto do z/OS

Depois de onze capítulos, o Padawan já acredita compreender bastante coisa.

Conhece:

✅ CALL

✅ LE

✅ CICS

✅ JES2

✅ GRS

✅ VVDS

✅ RMF

✅ SMF

✅ Telum

Até que um Sysprog abre IPCS.

Digita:

IP XDATA

E aparece:

PSA
CVT
TCB
ASCB
ACEE
RB

Padawan:

— O que é isso?

Veterano:

— O esqueleto do z/OS.


O Grande Segredo

No Mainframe tudo é Control Block.

Tudo.

Usuário.

Job.

CPU.

Storage.

Segurança.

Dataset.

Task.

Transação.

Tudo.


Visualmente


Programa COBOL

↓

TCB

↓

ASCB

↓

CVT

↓

PSA

↓

Hardware


PSA

Processor Storage Area


O primeiro bloco.

O mais importante.


Endereço:

00000000

Existe uma PSA.

Por processador.


Contém:

PSW

Interrupções

TCB Atual

Old PSW

New PSW

Save Areas


O PSW

Program Status Word


Coração da CPU.


Possui:

Endereço instrução

Modo

Máscaras

Estado


Exemplo

078D1000 80000000

Veteranos gostam.

Muito.


CVT

Communications Vector Table


O GPS do z/OS.


Tudo aponta.

Para CVT.


CVT aponta.

Para:

SMCA

JES

TCB

ASVT

Catalog

LPDB

CSA


Como encontrar

Assembler

L R1,CVTPID

IPCS também.


ASCB

Address Space Control Block


Representa.

Address Space.


Exemplo

TSO

DBM1

CICSA

JES2


Cada um.

Tem.

ASCB.


Contém

Nome

ASID

Usuário

TCBs

Storage


TCB

Já vimos.

Mas agora.

Internamente.


Task Control Block


Representa.

Thread.

Execução.

Task.


Contém.

Registradores.

Prioridade.

PSW.

RB.


RB

Request Block


Histórico.

Execução.


CALL.

Empilha RB.

Retorno.

Desempilha.


Visualmente


MAIN

↓

RB

↓

CALL A

↓

RB

↓

CALL B

↓

RB


ACEE

Accessor Environment Element


Favorito do RACF.


Representa.

Usuário.


Possui:

Userid

Groups

Permissões

Security Label


Quando faz:

TSO LOGON

ACEE nasce.


CSA

Common Storage Area


Memória compartilhada.


Todos acessam.


Perigosa.


Corrupção.

Pode derrubar sistema.


ECSA

Extended CSA


Versão ampliada.


Maior.

Melhor.


SQA

System Queue Area


Storage crítico.


Kernel usa.


Pouco espaço.

Muito importante.


LSQA

Local System Queue Area


Privada.

Por Address Space.


Subpools

Veteranos gostam.

Muito.


Exemplo

229

230

241


Storage.

Especializado.


Save Area

Assembler clássico.


72 bytes.


Exemplo

STM 14,12,12(13)

Salva.

Contexto.


IPCS

Melhor amigo.

Do Sysprog.


Pode mostrar.

PSA

TCB

ASCB

RB

ACEE


Exemplo

IP MTRACE

CEEDUMP

Também ajuda.


Mostra.

Stack.

Call chain.

Offsets.


O caminho de um CALL

Padawan escreve:

CALL 'PAGTO'

Internamente.

Pode ocorrer.


COBOL

↓

LE

↓

TCB

↓

RB

↓

PSW

↓

CPU

↓

RETURN



Tudo.

Em microssegundos.


O grande erro

Padawan pensa.

CALL é simples.

Veterano pensa.

CALL cria.

RB.

Storage.

Stack.

TCB Activity.

LE.

Heap.

PSW Update.


Ferramentas Jedi

IPCS

AMBLIST

CEEDUMP

RMF

SMF

VERBX

TRACE


Easter Egg Mainframe

Existe um grupo.

Capaz de olhar.

Isto.

TCB

RB

ACEE

PSA

CVT

ASCB

E dizer.

Em cinco minutos.

Quem é usuário.

Qual programa.

Onde caiu.

Quanto storage.

Qual PSW.

Qual registrador.


São conhecidos.

Como.

Os Senhores dos Control Blocks


Checklist Jedi

✅ Entender PSA

✅ Conhecer CVT

✅ Aprender ASCB

✅ Estudar TCB

✅ Entender RB

✅ Conhecer ACEE

✅ Respeitar CSA

✅ Estudar LSQA

✅ Explorar IPCS

✅ Ler CEEDUMP

✅ Conhecer Subpools


Filosofia Jedi – Parte 12

O Padawan acredita:

z/OS executa programas.

O Desenvolvedor experiente pensa:

z/OS gerencia recursos.

O Sysprog compreende:

z/OS é uma gigantesca coleção de Control Blocks conversando entre si.

E o Arquiteto IBM Z sabe que, por trás de um simples:

CALL 'SUBPGM'

existe um universo de PSA, CVT, TCB, RB, ACEE, Save Areas, registradores, PSWs e estruturas de controle que sustentam alguns dos sistemas mais importantes do planeta.




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