☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

segunda-feira, 15 de junho de 2020

CICS READNEXT & READPREV — A Jornada pela Estrada dos Registros do Reino VSAM

 

Bellacosa Mainframe e o acesso ao vsam via cics

☕ Um Café no Bellacosa Mainframe

CICS READNEXT & READPREV — A Jornada pela Estrada dos Registros do Reino VSAM

Quando um Programador COBOL Padawan Descobre que a Maior Sabedoria Não Está em Encontrar um Registro, Mas em Caminhar Pelo Caminho que Ele Revela

"Há quem pense que um grande programador é aquele que conhece todas as instruções do COBOL. Os velhos magos do mainframe sorriem diante dessa ideia. Eles sabem que o verdadeiro conhecimento nasce quando compreendemos como os dados percorrem silenciosamente os caminhos invisíveis do sistema."


Prólogo — A Biblioteca Perdida de Gondor

Imagine que você foi convocado por Gandalf para visitar a maior biblioteca já construída na Terra-média.

Não existe Google.

Não existe banco de dados SQL.

Não existe um campo de pesquisa.

Existem apenas milhões de pergaminhos cuidadosamente organizados em prateleiras infinitas.

Cada pergaminho possui um código.

Você procura o registro do cidadão número 000245987.

Um aprendiz sairia correndo entre as estantes procurando manualmente.

Um Mestre Arquivista simplesmente abriria o livro correto exatamente na página desejada.

O VSAM KSDS funciona exatamente assim.

E o CICS oferece um conjunto de comandos que transforma essa biblioteca em algo extremamente simples de navegar.

Esses comandos são:

  • STARTBR

  • READNEXT

  • READPREV

  • ENDBR

À primeira vista parecem comandos pequenos.

Na realidade, escondem décadas de engenharia da IBM.

Hoje vamos abrir essa caixa de segredos.


A filosofia do Browse

Antes de aprender READNEXT, precisamos abandonar um hábito mental muito comum.

Quando iniciamos no COBOL pensamos assim:

Quero um registro.

Então usamos:

READ

Mas sistemas corporativos raramente trabalham dessa forma.

Na maior parte do tempo o usuário deseja algo como:

"Mostre os próximos clientes."

"Liste os próximos pedidos."

"Passe para a próxima página."

"Volte um cliente."

"Continue de onde parei."

Isso muda completamente o problema.

Agora não estamos mais procurando um registro.

Estamos percorrendo um caminho.

É justamente aí que nasce o conceito de Browse.


O que significa Browse?

Browse significa literalmente:

Navegar.

Não pesquisar.

Não localizar.

Não buscar.

Navegar.

É como abrir um livro.

Você não procura cada página individualmente.

Você simplesmente vira a próxima folha.

Depois outra.

Depois outra.

Depois volta uma página.

Essa é exatamente a filosofia do Browse do CICS.


O protagonista invisível: STARTBR

Todo filme possui um herói.

Todo RPG possui um ponto inicial.

Todo programa CICS possui um STARTBR.

Sem ele nada acontece.

Seu trabalho não é ler registros.

Seu trabalho é muito mais importante.

Ele diz ao CICS:

"Prepare a viagem."

Exemplo:

EXEC CICS STARTBR
     FILE('CLIENTES')
     RIDFLD(WS-CHAVE)
END-EXEC.

Observe uma curiosidade interessante.

Nenhum registro foi retornado.

Nenhum dado foi copiado.

Nenhuma informação apareceu.

Então por que executar STARTBR?

Porque ele cria algo invisível.


A Sessão de Browse

Quando STARTBR é executado, o CICS cria internamente uma estrutura.

Essa estrutura guarda:

  • posição atual

  • chave corrente

  • ponteiro para o arquivo

  • direção da leitura

  • contexto da navegação

  • estado da operação

Pense nela como um marcador de páginas.

Imagine ler "O Senhor dos Anéis".

Você fecha o livro.

No dia seguinte abre exatamente onde parou.

O marcador fez isso.

STARTBR cria exatamente esse marcador.

Sem ele o CICS não sabe de onde continuar.


Uma comparação moderna

Hoje usamos streaming.

Netflix lembra onde paramos.

Spotify lembra a música.

Kindle lembra a página.

Google Docs lembra o cursor.

STARTBR fazia isso décadas antes da internet existir.


READNEXT — O Guardião da Estrada

Agora começa a aventura.

EXEC CICS READNEXT
     FILE('CLIENTES')
     INTO(WS-REG)
     RIDFLD(WS-ID)
END-EXEC.

Parece simples.

Mas internamente acontece uma verdadeira orquestra.

O CICS pergunta ao VSAM:

Qual registro vem depois deste?

O VSAM responde imediatamente.

Depois atualiza o marcador.

Depois entrega os dados.

Tudo isso em poucos microssegundos.


Como o VSAM sabe qual é o próximo?

Aqui encontramos uma das maiores genialidades do VSAM.

Muitos imaginam que ele percorra todo o arquivo.

Não.

Ele utiliza sua árvore de índices.

Visualmente:

                 Índice Raiz

               /             \

        Índice A          Índice B

        /     \            /     \

     Dados   Dados      Dados   Dados

Quando STARTBR encontra o registro inicial...

READNEXT simplesmente anda para frente.

Quando termina uma folha...

o índice aponta automaticamente para a próxima.

O programa COBOL nunca percebe isso.


A magia do KSDS

KSDS significa:

Key Sequenced Data Set

Ou seja...

os registros são armazenados obedecendo uma ordem lógica.

Veja:

000100 João

000150 Carlos

000220 Maria

000330 Pedro

000410 Ana

Não importa a ordem física.

Importa a ordem da chave.

READNEXT respeita exatamente essa sequência.


READPREV — O Retorno do Rei

Agora imagine uma tela de consulta.

O operador pressiona:

PF8

Próximo cliente.

Depois outro.

Depois outro.

Mas então lembra que esqueceu uma informação.

Pressiona:

PF7

O programa executa:

READPREV

E retorna ao registro anterior.

Parece simples.

Mas isso evita milhares de buscas.


Curiosidade pouco conhecida

Muitos iniciantes acreditam que READPREV faz o disco girar ao contrário.

Não.

O VSAM utiliza novamente sua árvore B.

Ele encontra rapidamente o registro anterior utilizando o índice.

Essa estrutura é extremamente eficiente.

Mesmo arquivos com dezenas de milhões de registros continuam rápidos.


O Browse lembra um Cursor SQL?

Muito.

Veja.

SQL

DECLARE CURSOR

OPEN

FETCH NEXT

FETCH PRIOR

CLOSE

Agora compare.

CICS

STARTBR

READNEXT

READPREV

ENDBR

São filosofias quase idênticas.

Não por acaso.

Muitos conceitos modernos nasceram justamente dos ambientes mainframe.


O ciclo completo

Uma navegação típica acontece assim.

STARTBR

↓

READNEXT

↓

READNEXT

↓

READNEXT

↓

READPREV

↓

READNEXT

↓

READNEXT

↓

ENDBR

Simples.

Elegante.

Confiável.


E o ENDBR?

Todo começo precisa de um fim.

Quando terminamos:

EXEC CICS ENDBR
     FILE('CLIENTES')
END-EXEC.

O CICS remove:

  • ponteiros

  • buffers

  • contexto

  • sessão

  • recursos internos

Imagine esquecer ENDBR.

Seria como abandonar centenas de livros abertos pela biblioteca.

Alguém precisará organizá-los depois.

Por isso ENDBR é obrigatório.


O segredo dos códigos RESP

Programadores iniciantes costumam cometer um erro clássico.

Ignoram RESP.

Jamais faça isso.

Exemplo:

RESP = NORMAL

Tudo certo.


RESP = ENDFILE

Fim da navegação.

Não é erro.


RESP = NOTFND

Registro não localizado.


RESP = INVREQ

Pedido inválido.

Geralmente STARTBR inexistente.


RESP = FILENOTFOUND

Arquivo indisponível.


RESP = LOCKED

Registro bloqueado.


O perigo dos loops infinitos

Imagine:

PERFORM UNTIL FIM

READNEXT

END-PERFORM

Sem verificar ENDFILE.

O resultado?

Loop eterno.

O programa continua tentando ler além do último registro.

Esse é um dos erros mais comuns encontrados em entrevistas técnicas.


GTEQ — Uma joia escondida

Suponha este arquivo.

100

200

300

400

500

Você procura:

250

Sem GTEQ.

Resultado:

NOTFND

Com GTEQ.

Resultado:

300

Ou seja:

Comece pelo primeiro registro maior ou igual.

É fantástico para consultas por faixa.


Pesquisas parciais

Imagine procurar CEPs.

13000

13010

13020

13035

13080

13100

O operador deseja apenas:

130

O STARTBR posiciona no primeiro.

READNEXT continua lendo.

Quando chega:

131

A pesquisa termina.

Sem varrer milhões de registros.


Paginação muito antes da Web

Hoje chamamos isso de paginação.

Mas o CICS fazia isso nos anos 70.

Tela.

Cliente 1

Cliente 2

Cliente 3

Cliente 4

Cliente 5

PF8.

Mais cinco.

PF8.

Mais cinco.

PF7.

Cinco anteriores.

Décadas antes do JavaScript.

Décadas antes do HTML.

Décadas antes do React.


Performance impressionante

Imagine um banco.

Arquivo:

40 milhões de clientes.

Você quer mostrar apenas vinte.

READNEXT lê somente vinte.

Não quarenta milhões.

É essa eficiência que tornou o mainframe lendário.


O que acontece por trás dos bastidores?

Enquanto você escreve apenas:

READNEXT

O CICS executa dezenas de tarefas:

✔ valida a Browse Session

✔ verifica autorização RACF

✔ verifica integridade

✔ localiza buffers

✔ identifica a posição corrente

✔ percorre a árvore do VSAM

✔ copia dados

✔ atualiza RIDFLD

✔ movimenta INTO

✔ atualiza ponteiros

✔ retorna RESP

Tudo isso acontece invisivelmente.


Boas práticas de um Programador Jedi

Nunca faça:

STARTBR

READNEXT

ABEND

...

Sem ENDBR.

Use sempre tratamento de exceção.

Outra boa prática:

Nunca deixe Browse aberto durante muito tempo.

Quanto menor a duração da sessão, melhor para o ambiente.


Armadilhas clássicas

Esquecer STARTBR

READNEXT falha.


Esquecer ENDBR

Recursos permanecem ocupados.


Ignorar RESP

Loops infinitos.


Fazer READ comum durante o Browse

Perde desempenho.


Atualizar registros sem entender bloqueios

Pode causar conflitos de concorrência.


Curiosidades Históricas

Durante as décadas de 1980 e 1990 praticamente todo caixa bancário utilizava PF7 e PF8.

PF8

READNEXT

PF7

READPREV

Milhares de operadores trabalhavam assim diariamente.

Sem mouse.

Sem interface gráfica.

Mesmo assim conseguiam navegar milhões de registros mais rapidamente do que muitos sistemas modernos.


Dicas para entrevistas técnicas

Se o entrevistador perguntar:

Qual a sequência correta?

Responda imediatamente.

STARTBR

↓

READNEXT ou READPREV

↓

ENDBR

Outra pergunta clássica:

READNEXT funciona sem STARTBR?

Resposta:

Não.

Porque não existe posição inicial.


Easter Egg — A Sociedade do Browse 🧙‍♂️💍

No universo de O Senhor dos Anéis, imagine que o VSAM KSDS seja a gigantesca biblioteca de Minas Tirith, onde cada tomo contém a história de um habitante da Terra-média, organizado rigorosamente pelos escribas de Gondor.

STARTBR é Gandalf abrindo o antigo mapa dos reinos e indicando onde a Sociedade iniciará sua jornada. Sem esse mapa, ninguém sabe por onde seguir.

READNEXT é Aragorn conduzindo a comitiva pela estrada principal, avançando de vila em vila, encontrando cada novo aliado na ordem correta, sem jamais se perder.

READPREV é Legolas olhando para trás do grupo, retornando alguns passos para verificar se ninguém ficou para trás ou se alguma pista importante foi esquecida no caminho.

ENDBR é o momento em que a missão termina, o mapa é cuidadosamente enrolado e devolvido aos arquivos de Minas Tirith. Nada permanece aberto, nenhum recurso é desperdiçado e a biblioteca está pronta para a próxima expedição.

Existe ainda um personagem invisível: a árvore B (B-tree) do VSAM. Ela pode ser comparada às Águias da Terra-média. Quase ninguém as vê trabalhando, mas são elas que conhecem todos os caminhos e permitem que a jornada aconteça com rapidez extraordinária. Sem elas, percorrer milhões de registros seria como atravessar Mordor a pé sem qualquer orientação.

O verdadeiro herói desta história não é READNEXT nem READPREV.

É a inteligência do VSAM, construída ao longo de décadas de engenharia, permitindo que aplicações COBOL executem consultas em volumes gigantescos de dados com uma eficiência que continua impressionando até os dias atuais.


Conclusão — A Sabedoria dos Antigos Arquivistas

Quando um programador iniciante aprende READNEXT e READPREV, pode imaginar que está apenas decorando mais alguns comandos da linguagem CICS. Porém, essa impressão desaparece à medida que compreende o que realmente acontece nos bastidores.

Esses comandos representam uma filosofia de desenvolvimento que nasceu muito antes da computação moderna: não acessar dados de forma aleatória quando existe um caminho inteligente para percorrê-los. O Browse do CICS reduz processamento, aproveita a organização do VSAM KSDS, reutiliza a posição corrente e transforma milhões de registros em uma trilha organizada que pode ser percorrida para frente e para trás com naturalidade.

Não é por acaso que bancos, seguradoras, companhias aéreas e governos utilizam esse mecanismo há décadas. Em sistemas onde cada microssegundo conta e cada transação precisa ser confiável, navegar corretamente pelos dados é tão importante quanto encontrá-los.

No universo Bellacosa Mainframe, costumo dizer que um Programador COBOL Padawan aprende primeiro a fazer um READ. Um profissional experiente aprende quando usar STARTBR. Mas um verdadeiro Mestre do Mainframe entende que o maior poder nunca esteve em localizar um único registro, e sim em conduzir toda a jornada pelos dados com elegância, eficiência e respeito à arquitetura construída pelos antigos engenheiros da IBM.

E, assim como Frodo descobriu que o valor da jornada era muito maior do que o destino final, o programador também percebe que dominar STARTBR, READNEXT, READPREV e ENDBR é mais do que conhecer comandos: é aprender uma das artes mais refinadas da programação transacional em CICS, uma tradição que continua viva após mais de meio século de evolução do IBM Z.

segunda-feira, 18 de fevereiro de 2019

O Mistério da Biblioteca Infinita : Quando um Jovem Programador COBOL Descobriu que READNEXT e READPREV Eram Muito Mais do que Simples Comandos

 

Bellacosa Mainframe e o misterio da biblioteca infinita

☕ Um Café no Bellacosa Mainframe

O Mistério da Biblioteca Infinita

Quando um Jovem Programador COBOL Descobriu que READNEXT e READPREV Eram Muito Mais do que Simples Comandos

"Há portas que nunca deveriam ser abertas sem conhecer o caminho de volta. Nos corredores silenciosos do CICS existe uma delas. Seu nome é STARTBR..."


O relógio marcava 2h17 da madrugada.

O CPD permanecia mergulhado naquela penumbra azul característica das salas onde vivem os grandes mainframes. O som dos ventiladores parecia a respiração lenta de uma criatura adormecida. Os LEDs piscavam em ritmos quase hipnóticos.

Na pequena copa do prédio, o café já havia passado do ponto. Forte. Amargo. Exatamente como gostavam os velhos programadores COBOL.

Foi naquele instante que Augusto, recém-chegado ao time de desenvolvimento, encontrou um senhor de cabelos completamente brancos observando uma impressão contínua de listagens.

— Está procurando alguma coisa, rapaz?

— Estou tentando entender por que meu programa não encontra o próximo registro...

O velho sorriu.

— Ah... então chegou a hora de conhecer o Mistério da Biblioteca Infinita.

Naquela noite Augusto aprenderia algo que poucos cursos ensinam: READNEXT e READPREV não são apenas comandos. Eles representam uma filosofia inteira de navegação dentro do VSAM.

Pegue uma xícara de café.

A investigação começa agora.


Capítulo 1 — O Erro de Todo Iniciante

Todo iniciante em COBOL/CICS passa pela mesma fase.

Ele aprende:

EXEC CICS READ

e acredita que resolveu todos os problemas do universo.

Afinal...

Se READ encontra registros...

por que existiriam READNEXT e READPREV?

A resposta parece simples.

Mas esconde décadas de engenharia da IBM.

Imagine um arquivo VSAM contendo:

  • 25 milhões de clientes

  • 180 milhões de contas

  • 2 bilhões de transações históricas

Você realmente faria uma pesquisa completa para mostrar o cliente seguinte?

Claro que não.

Seria como procurar novamente uma palavra no dicionário toda vez que desejasse ler a próxima linha.


A Biblioteca Infinita

Imagine entrar em uma biblioteca.

Você procura um livro específico.

O bibliotecário entrega exatamente aquele volume.

Isso é READ.

Agora imagine outra situação.

Você deseja caminhar pela estante.

Livro após livro.

Prateleira após prateleira.

Sem voltar ao balcão.

Essa é exatamente a ideia do Browse.

Você deixa de perguntar:

"Encontre este registro."

e passa a dizer:

"Estou aqui. Continue andando."


O Primeiro Segredo: STARTBR

Existe uma regra sagrada no CICS.

Nenhum Browse nasce sozinho.

Sempre existe um ritual de abertura.

Esse ritual chama-se:

EXEC CICS STARTBR

Muitos iniciantes imaginam que STARTBR apenas "começa".

Na realidade...

ele constrói toda uma estrutura invisível.

É como entregar um mapa ao explorador antes que ele entre na floresta.

Sem mapa...

não existe caminho.


O Que o CICS Guarda em Segredo?

Quando STARTBR é executado, diversas informações ficam armazenadas internamente.

Entre elas:

✔ posição atual

✔ arquivo aberto

✔ chave inicial

✔ sentido da navegação

✔ ponteiros do índice VSAM

✔ contexto da sessão

Ou seja...

o CICS passa a lembrar exatamente onde você está.

Isso é extremamente importante.

Porque READNEXT jamais procura "o próximo".

Ele pergunta ao CICS:

"Qual é o próximo registro depois daquele onde estamos?"

Parece detalhe.

Mas muda completamente o funcionamento interno.


A Diferença Entre Procurar e Caminhar

Imagine duas pessoas.

Pessoa A.

Toda vez que precisa mudar de casa pega um GPS, digita o endereço e recalcula toda a rota.

Pessoa B.

Já está caminhando pela rua.

Ela apenas dá mais um passo.

Quem chega primeiro?

O Browse é exatamente isso.

READ faz pesquisas.

READNEXT continua caminhando.


O Índice Invisível do VSAM

Aqui existe uma curiosidade fascinante.

Poucos iniciantes percebem que um KSDS funciona muito parecido com um enorme índice de livro.

Você não percorre todas as páginas.

Você vai direto ao capítulo.

Depois apenas continua lendo.

É isso que torna STARTBR tão eficiente.

Primeiro localiza.

Depois navega.


O Segundo Segredo: RIDFLD

Existe um detalhe que costuma derrubar muitos programadores durante entrevistas técnicas.

Observe:

RIDFLD(WS-CLIENTE)

Quase todo iniciante pensa:

"Essa variável apenas informa onde começar."

Errado.

Ela muda durante o Browse.

Depois de cada READNEXT...

o próprio CICS grava nela a chave do registro corrente.

Ela deixa de ser apenas entrada.

Passa a ser entrada e saída.

Esse pequeno detalhe explica inúmeros bugs encontrados em produção.


A Máquina do Tempo

Imagine o arquivo:

1000
1010
1020
1030
1040
1050

STARTBR em:

1020

Primeiro READNEXT:

1020

Segundo:

1030

Terceiro:

1040

Observe.

Nunca houve nova pesquisa.

O cursor simplesmente continuou andando.


READPREV — O Caminho de Volta

Todo explorador precisa voltar para casa.

É aqui que entra:

READPREV

Ele faz exatamente o contrário.

1050

↓

1040

↓

1030

↓

1020

Sem READPREV seria necessário fechar tudo.

Executar novo STARTBR.

Localizar novamente.

Muito mais caro.

Muito mais lento.


O Grande Truque do Browse

Pouca gente sabe.

Você pode mudar de direção quantas vezes desejar.

READNEXT

READNEXT

READNEXT

READPREV

READPREV

READNEXT

O cursor continua existindo.

Ele apenas muda de sentido.

É como caminhar por um corredor.

Você não desaparece para reaparecer alguns metros atrás.

Você simplesmente vira o corpo.


Bastidores do CICS

Enquanto seu COBOL executa apenas uma linha:

READNEXT

O CICS realiza dezenas de operações.

Entre elas:

• verifica autorização

• consulta a sessão

• valida o Browse

• consulta o índice VSAM

• posiciona buffers

• realiza I/O

• atualiza ponteiros

• copia registro

• atualiza RIDFLD

• retorna RESP

Tudo isso em poucos microssegundos.

É por isso que tantas pessoas chamam o CICS de uma verdadeira obra-prima da engenharia de software.


O Erro que Todo Mundo Comete

Imagine esquecer:

ENDBR

Nada explode.

O programa aparentemente funciona.

Mas...

internamente...

a sessão continua aberta.

Em ambientes pequenos isso quase não é percebido.

Agora imagine:

25 mil usuários.

Todos esquecendo ENDBR.

As estruturas de Browse começam a se acumular.

Recursos permanecem ocupados.

Memória continua sendo utilizada.

É por isso que os programadores antigos repetem quase como um mantra:

"Todo STARTBR merece um ENDBR."


A Lição do Operador 3270

Durante décadas, milhões de operadores utilizaram terminais IBM 3270.

Eles apertavam:

PF7

PF8

Achando que apenas rolavam uma tela.

Na realidade...

atrás daquela tecla...

existia uma sequência semelhante a esta:

STARTBR

↓

READNEXT

↓

READNEXT

↓

READNEXT

↓

ENDBR

Cada toque em PF8 podia representar diversas leituras do VSAM.

A interface era simples.

O trabalho invisível era gigantesco.


Um Caso Real de Banco

Imagine um gerente consultando clientes.

Ele digita:

Conta:

458700

O sistema faz:

STARTBR

na conta 458700.

Depois:

READNEXT

458701

READNEXT

458702

READNEXT

458703

Agora o gerente percebe que passou do cliente desejado.

Pressiona:

Anterior.

O sistema executa:

READPREV

458702

Tudo instantaneamente.

Sem pesquisar novamente.


Curiosidade Histórica

Nas décadas de 1970 e 1980, muitos sistemas de cadastro nacional, bancos e companhias aéreas já utilizavam Browse exatamente como fazemos hoje.

Enquanto computadores pessoais ainda utilizavam fitas cassete e disquetes flexíveis, o CICS já navegava milhões de registros em tempo real.

Muita tecnologia moderna reinventou conceitos que o mainframe domina há mais de quarenta anos.


Easter Egg Bellacosa ☕

Os veteranos costumavam brincar:

"READ encontra um cliente.

READNEXT encontra a família inteira."

A piada faz sentido.

READ resolve uma pergunta.

READNEXT conta uma história.


Outra Curiosidade Pouco Conhecida

Você não é obrigado a começar pelo primeiro registro.

Pode iniciar exatamente na região desejada.

Por exemplo.

Clientes entre:

700000

e

799999

STARTBR começa em:

700000

Depois basta continuar navegando.

Essa técnica economiza enorme quantidade de processamento.


O Papel do RESP

Nunca ignore:

RESP

Ele é o detetive do seu programa.

É ele quem informa:

✔ leitura normal

✔ fim do arquivo

✔ registro inexistente

✔ arquivo indisponível

✔ erro de sequência

Programadores experientes quase nunca confiam apenas no sucesso.

Eles sempre perguntam ao CICS:

"Como foi a leitura?"


O Fluxo Completo

Uma aplicação típica faz:

STARTBR

↓

READNEXT

↓

READNEXT

↓

READNEXT

↓

READPREV

↓

READNEXT

↓

ENDBR

Esse ciclo pode durar poucos milissegundos.

Ou permanecer ativo durante toda uma consulta feita pelo usuário.


Comparando com um Livro

Imagine um romance policial.

READ é abrir diretamente na página 287.

READNEXT é virar a página.

READPREV é voltar uma página.

STARTBR é abrir o livro.

ENDBR é fechá-lo.

Parece simples.

Mas imagine esse livro contendo bilhões de páginas.

É exatamente esse o desafio que o VSAM resolve diariamente.


Dicas de Ouro para Quem Está Começando

✔ Sempre execute STARTBR antes da primeira navegação.

✔ Nunca esqueça de finalizar com ENDBR.

✔ Trate cuidadosamente os códigos de RESP e RESP2; eles são fundamentais para identificar condições como fim de arquivo, registros não encontrados ou outros eventos específicos.

✔ Não altere RIDFLD durante uma sessão de Browse sem compreender o impacto no posicionamento.

✔ Use READNEXT para consultas sequenciais e listagens.

✔ Utilize READPREV para implementar botões Anterior, navegação reversa e revisões de dados.

✔ Lembre-se de que READNEXT e READPREV apenas leem registros; alterações exigem comandos específicos, como READ UPDATE e REWRITE.

✔ Em telas BMS, combine Browse com PF7/PF8 para oferecer uma experiência fluida ao usuário.

✔ Em sistemas de alto volume, um Browse bem projetado reduz chamadas desnecessárias ao índice VSAM, economiza CPU e melhora o tempo de resposta.


A Pergunta que Sempre Cai na Entrevista

O entrevistador sorri e pergunta:

"Qual a diferença entre READ e READNEXT?"

O candidato comum responde:

"READNEXT lê o próximo."

O candidato experiente responde:

"READ recupera um registro específico por chave. READNEXT faz parte de uma sessão de Browse iniciada por STARTBR, reutilizando o posicionamento interno do VSAM para navegar sequencialmente sem repetir pesquisas completas. READPREV permite retornar registros anteriores e ENDBR encerra a sessão liberando os recursos."

Essa resposta mostra que você compreende não apenas a sintaxe, mas a arquitetura por trás do CICS.


O Último Mistério

Quando Augusto terminou sua última xícara de café, olhou novamente para o velho programador.

— Então READNEXT nunca procurou o próximo registro?

O veterano sorriu discretamente.

— Não, rapaz...

Ele apenas continua um caminho que alguém já abriu.

Apontou para o enorme IBM Z iluminado atrás do vidro e concluiu:

— O segredo do CICS nunca foi encontrar informações. Foi lembrar exatamente onde você estava.

Naquele instante, Augusto compreendeu algo que nenhum manual explicava com tanta clareza.

Entre um STARTBR e um ENDBR, existe uma pequena viagem silenciosa através de uma biblioteca digital com milhões de páginas. E cada READNEXT ou READPREV é apenas mais um passo pelos corredores invisíveis do VSAM, onde o verdadeiro poder do Mainframe não está na velocidade de ler dados, mas na inteligência de nunca se perder dentro deles.

Na velha copa do CPD, o café já estava frio. Mas, para um programador COBOL, havia noites em que um único comando era suficiente para revelar um dos maiores segredos da computação corporativa. E, como diriam os antigos mestres do Bellacosa Mainframe:

"Quem domina o Browse deixa de procurar registros. Passa a caminhar por eles."

 

quinta-feira, 5 de julho de 2012

☕🔥 CICS NA PRÁTICA — EXEMPLOS REAIS COM RESP E RESP2

 

Bellacosa Mainframe uso correto do resp1 e resp2 em comandos cics

☕🔥 CICS NA PRÁTICA — EXEMPLOS REAIS COM RESP E RESP2

Como Programadores Enterprise Tratam Erros, Controle Transacional e Exceções no Mundo IBM Z

No CICS profissional…

não basta executar comandos.

Você precisa:

  • validar retorno,

  • tratar erro,

  • evitar abend,

  • proteger integridade,

  • controlar concorrência,

  • garantir recovery.

E é aqui que entram:

RESP()
RESP2()

🔥 O QUE É RESP?

RESP:

  • retorna o código principal do resultado do comando CICS.

Exemplo:

EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     INTO(WS-REG)
     RESP(WS-RESP)
END-EXEC

☕ O QUE É RESP2?

RESP2:

  • retorna detalhes adicionais do erro.

É o “subcódigo”.


Exemplo clássico

RESP:

NOTFND

RESP2:

80

Indica detalhe interno específico do recurso.


🔥 PADRÃO PROFISSIONAL

Todo sistema enterprise usa algo parecido com isto:

01 WS-RESP     PIC S9(8) COMP.
01 WS-RESP2    PIC S9(8) COMP.

☕ EXEMPLO 1 — READ FILE COM VALIDAÇÃO


Objetivo

Ler cliente VSAM.


EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CLIENTE-ID)
     INTO(WS-CLIENTE)
     LENGTH(WS-LEN)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

EVALUATE WS-RESP

    WHEN DFHRESP(NORMAL)

         DISPLAY 'CLIENTE ENCONTRADO'

    WHEN DFHRESP(NOTFND)

         DISPLAY 'CLIENTE NAO EXISTE'
         DISPLAY 'RESP2: ' WS-RESP2

    WHEN DFHRESP(NOTOPEN)

         DISPLAY 'ARQUIVO FECHADO'

    WHEN OTHER

         DISPLAY 'ERRO CICS'
         DISPLAY 'RESP=' WS-RESP
         DISPLAY 'RESP2=' WS-RESP2

END-EVALUATE

🔥 EXPLICAÇÃO DOS PARÂMETROS

ParâmetroFunção
FILENome lógico do FCT
RIDFLDChave VSAM
INTOÁrea destino
LENGTHTamanho do registro
RESPCódigo principal
RESP2Detalhe técnico

☕ EXEMPLO 2 — WRITE COM DUPREC


EXEC CICS WRITE
     FILE('CLIENTE')
     FROM(WS-REGISTRO)
     RIDFLD(WS-CHAVE)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

IF WS-RESP = DFHRESP(DUPREC)

    DISPLAY 'CHAVE DUPLICADA'
    DISPLAY 'RESP2=' WS-RESP2

END-IF

🔥 O QUE É DUPREC?

Duplicate Record.

Ocorre quando:

  • chave já existe no KSDS.


☕ EXEMPLO 3 — READ UPDATE + REWRITE


Cenário

Atualização segura com lock.


EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     INTO(WS-REG)
     UPDATE
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

UPDATE

Esse parâmetro:

  • trava o registro,

  • impede alteração simultânea.


Depois:

MOVE 'ATIVO' TO WS-STATUS

EXEC CICS REWRITE
     FILE('CLIENTE')
     FROM(WS-REG)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

☕ ERRO COMUM

Esquecer:

  • REWRITE

  • UNLOCK

  • SYNCPOINT

Resultado:
🔥 lock pendurado.


🔥 EXEMPLO 4 — HANDLE CONDITION


EXEC CICS HANDLE CONDITION
     NOTFND(SEM-REG)
     DUPREC(REG-DUP)
     ERROR(ERRO-GERAL)
END-EXEC

Como funciona?

Se ocorrer:

  • NOTFND → desvia para SEM-REG

  • DUPREC → REG-DUP

  • ERROR → ERRO-GERAL


Vantagem

Evita:

IF RESP = ...

em todos comandos.


☕ EXEMPLO 5 — LINK


EXEC CICS LINK
     PROGRAM('CADCLI')
     COMMAREA(WS-COMMAREA)
     LENGTH(LENGTH OF WS-COMMAREA)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

Explicação

ParâmetroFunção
PROGRAMPrograma chamado
COMMAREAÁrea compartilhada
LENGTHTamanho
RESPResultado

O LINK retorna

Diferente do XCTL.


☕ EXEMPLO 6 — XCTL


EXEC CICS XCTL
     PROGRAM('MENU001')
     COMMAREA(WS-COMM)
     LENGTH(100)
END-EXEC

Diferença crítica

LINKXCTL
retornanão retorna
empilhasubstitui
subrotinatransferência

🔥 EXEMPLO 7 — RETURN COMMAREA


EXEC CICS RETURN
     TRANSID('MEN1')
     COMMAREA(WS-COMM)
     LENGTH(LENGTH OF WS-COMM)
END-EXEC

TRANSID

Transação reiniciada quando usuário pressionar ENTER.


COMMAREA

Preserva contexto.


☕ EXEMPLO 8 — SEND MAP


EXEC CICS SEND MAP('TELA01')
     MAPSET('MAPSET1')
     FROM(WS-MAPA)
     ERASE
     CURSOR
     RESP(WS-RESP)
END-EXEC

Explicação

ParâmetroFunção
MAPNome do mapa
MAPSETBiblioteca BMS
FROMDados
ERASELimpa tela
CURSORPosiciona cursor

☕ EXEMPLO 9 — RECEIVE MAP


EXEC CICS RECEIVE MAP('TELA01')
     MAPSET('MAPSET1')
     INTO(WS-MAPA)
     RESP(WS-RESP)
END-EXEC

O RECEIVE captura

  • ENTER

  • PFKEY

  • campos digitados


🔥 EXEMPLO 10 — WRITEQ TS


EXEC CICS WRITEQ TS
     QUEUE('FILA001')
     FROM(WS-DADOS)
     LENGTH(200)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

TS Queue

Usada para:

  • sessão,

  • paginação,

  • cache,

  • workflow.


☕ EXEMPLO 11 — READQ TS


EXEC CICS READQ TS
     QUEUE('FILA001')
     INTO(WS-DADOS)
     ITEM(1)
     RESP(WS-RESP)
END-EXEC

ITEM

Lê item específico da fila.


🔥 EXEMPLO 12 — STARTBR + READNEXT


STARTBR

EXEC CICS STARTBR
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     GTEQ
     RESP(WS-RESP)
END-EXEC

GTEQ

Começa:

  • na chave,

  • ou próxima maior.


READNEXT

EXEC CICS READNEXT
     FILE('CLIENTE')
     INTO(WS-REG)
     RIDFLD(WS-CHAVE)
     RESP(WS-RESP)
END-EXEC

ENDFILE

Fim do browse.


☕ EXEMPLO 13 — SYNCPOINT


EXEC CICS SYNCPOINT
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

O que ele faz?

Commit de:

  • VSAM

  • DB2

  • MQ

  • TS recoverable


ROLLBACK

EXEC CICS SYNCPOINT ROLLBACK
END-EXEC

🔥 EXEMPLO 14 — ABEND CONTROLADO


EXEC CICS ABEND
     ABCODE('ER01')
     NODUMP
END-EXEC

ABCODE

Código customizado.


NODUMP

Evita dump completo.


☕ EXEMPLO 15 — GETMAIN


EXEC CICS GETMAIN
     SET(WS-PTR)
     LENGTH(1024)
     INITIMG(X'00')
     RESP(WS-RESP)
END-EXEC

INITIMG

Inicializa memória.


☕ EXEMPLO 16 — FREEMAIN


EXEC CICS FREEMAIN
     DATAPOINTER(WS-PTR)
     RESP(WS-RESP)
END-EXEC

ERRO CLÁSSICO

Não liberar storage:
🔥 SOS CONDITION.


🔥 EXEMPLO 17 — ENQ / DEQ


ENQ

EXEC CICS ENQ
     RESOURCE('CLIENTE001')
     LENGTH(10)
     RESP(WS-RESP)
END-EXEC

RESOURCE

Nome lógico protegido.


DEQ

EXEC CICS DEQ
     RESOURCE('CLIENTE001')
END-EXEC

☕ EXEMPLO 18 — START


EXEC CICS START
     TRANSID('TRN1')
     FROM(WS-DADOS)
     LENGTH(100)
     INTERVAL(000500)
     RESP(WS-RESP)
END-EXEC

INTERVAL

Dispara:

  • após 5 minutos.


🔥 EXEMPLO 19 — DELAY


EXEC CICS DELAY
     FOR SECONDS(5)
END-EXEC

DELAY

Suspende task.


☕ EXEMPLO 20 — WRITE OPERATOR


EXEC CICS WRITE OPERATOR
     TEXT('ERRO CRITICO')
     TEXTLENGTH(13)
     RESP(WS-RESP)
END-EXEC

Envia mensagem para

  • console operador,

  • automação,

  • suporte.


🔥 O SEGREDO DOS SISTEMAS ENTERPRISE

Os melhores sistemas CICS:

  • validam RESP sempre,

  • usam HANDLE CONDITION estrategicamente,

  • controlam locks,

  • fazem rollback corretamente,

  • evitam storage leak,

  • minimizam pseudo-conversação incorreta.


☕ CONCLUSÃO

Programar CICS profissionalmente não é apenas “executar comandos”.

É entender:

  • concorrência,

  • recovery,

  • sincronização,

  • gerenciamento de recursos,

  • integridade transacional,

  • comportamento interno da região CICS.

E é exatamente isso que separa:

  • um programador COBOL comum,
    de

  • um verdadeiro engenheiro IBM Z enterprise.

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