 |
| Bellacosa Mainframe e as tecnicas de conversação em programas CICS parte I |
☕ Um Café no Bellacosa Mainframe
CICS Conversacional e Pseudo-Conversacional
Parte 1 — Das Conversas Eternas ao Modelo que Move o Mundo
"Salve, jovem Padawan Mainframe! Pegue seu café, abra uma sessão do SDSF, deixe o IPCS de prontidão e venha comigo entender uma das maiores sacadas de engenharia já criadas pela IBM. Hoje vamos falar sobre dois conceitos que sustentam boa parte das aplicações bancárias do planeta: CICS Conversacional e Pseudo-Conversacional."
O que é uma aplicação Conversacional?
Imagine que você está conversando com alguém pelo telefone.
Você liga.
A pessoa atende.
A ligação permanece aberta.
Vocês conversam.
Você pensa.
Procura um documento.
Vai tomar café.
Volta.
Continua falando.
Finalmente desliga.
Foi exatamente esta filosofia que inspirou o primeiro modelo de aplicações CICS.
Modelo Conversacional
O programa permanece residente na memória durante toda a interação com o usuário.
Visualmente:
Usuário
│
EXEC CICS RECEIVE
│
Programa permanece ativo
│
Processa
│
EXEC CICS SEND
│
Espera usuário
│
EXEC CICS RECEIVE
│
Processa
│
EXEC CICS SEND
│
...
│
EXEC CICS RETURN
O programa nunca sai da memória.
A task permanece viva.
A TCA continua alocada.
O TCB continua associado.
A área de trabalho permanece disponível.
Tudo fica esperando.
Inclusive o usuário.
O problema
Vamos imaginar um banco em 1982.
Existem:
5.000 terminais.
3.000 usuários.
2.000 consultas simultâneas.
Cada usuário fica parado.
Lendo a tela.
Pensando.
Conferindo CPF.
Procurando documentos.
Tomando café.
Atendendo telefone.
Conversando.
Enquanto isso...
O programa continua residente.
A task continua viva.
O CICS continua consumindo recursos.
A memória continua ocupada.
O nascimento da pseudo-conversação
Os engenheiros da IBM olharam para isso e disseram:
"Por que manter um programa carregado esperando um ser humano pensar?"
E a resposta foi brilhante.
Não vamos esperar.
Vamos embora.
Quando o usuário voltar...
Criamos outra task.
Recuperamos o estado.
Continuamos.
Nascia a pseudo-conversação.
O que é Pseudo-Conversação?
A pseudo-conversação é um modelo onde o programa não fica esperando.
Ele:
Mostra a tela.
Encerra a task.
Libera recursos.
Quando o usuário aperta ENTER...
Uma nova task é criada.
Tudo continua.
Como se nada tivesse acontecido.
Fluxo
Usuário
│
Executa CLI1
│
Programa COBOL
│
SEND MAP
│
RETURN TRANSID
COMMAREA
│
Task termina
=====================
Usuário digita
ENTER
=====================
Nova Task
Recebe COMMAREA
RECEIVE MAP
Processa
SEND MAP
RETURN
É quase uma ilusão.
Parece conversacional.
Mas não é.
Por isso o nome:
Pseudo-Conversacional.
Comparando os dois modelos
| Característica | Conversacional | Pseudo |
|---|---|---|
| Task ativa | Sim | Não |
| Programa residente | Sim | Não |
| Consome memória | Alta | Baixa |
| Escalabilidade | Ruim | Excelente |
| Usado atualmente | Raro | Padrão |
| Ideal para milhares usuários | Não | Sim |
Por que a IBM venceu?
Porque ela resolveu um problema gigantesco.
Imagine.
100 mil usuários.
Cada um esperando.
Em modelo conversacional.
Seria inviável.
No pseudo.
As tasks duram poucos milissegundos.
O usuário pensa.
Mas o mainframe trabalha em outra coisa.
Analogia moderna
Conversacional:
Você deixa o Uber esperando na porta enquanto toma banho.
Pseudo-conversacional:
Você pede outro Uber quando estiver pronto.
O custo muda completamente.
O segredo: COMMAREA
A memória da aplicação.
Entre uma task e outra.
Exemplo:
01 WS-COMM.
05 WS-CLIENTE.
10 WS-CODIGO PIC 9(6).
10 WS-NOME PIC X(30).
10 WS-PAGINA PIC 99.
10 WS-MODO PIC X.
Primeira execução
Como descobrir?
Usando:
EIBCALEN
IF EIBCALEN = ZERO
PERFORM PRIMEIRA-VEZ
END-IF
Primeira vez.
Sem COMMAREA.
Retorno
IF EIBCALEN > ZERO
PERFORM RETORNO
END-IF
Existe contexto.
Usuário voltou.
Salvando estado
EXEC CICS RETURN
TRANSID('CLI1')
COMMAREA(WS-COMM)
LENGTH(100)
END-EXEC.
CICS guarda.
Task termina.
Memória liberada.
Criando nova task
Usuário aperta ENTER.
CICS cria:
Nova TCA
Nova Task
Novo TCB
Novo EIB
Mas entrega a COMMAREA.
Tudo continua.
Mágica.
Engenharia.
IBM.
O papel do BMS
Sem BMS.
Pseudo-conversação seria muito mais complicada.
Precisaríamos:
Salvar coordenadas.
Salvar cursor.
Salvar atributos.
Salvar campos.
O BMS faz tudo isso.
SEND MAP
Mostra tela.
EXEC CICS SEND MAP
MAP('TELA1')
MAPSET('CLIMAP')
ERASE
FREEKB
END-EXEC.
RECEIVE MAP
Recebe dados.
EXEC CICS RECEIVE MAP
MAP('TELA1')
MAPSET('CLIMAP')
INTO(TELA1I)
END-EXEC.
Curiosidade Bellacosa Mainframe
Muitos sistemas bancários desenvolvidos em 1985 ainda utilizam exatamente este modelo.
Mudou o hardware.
Mudou o storage.
Mudou a CPU.
Mudou a interface.
Mas a arquitetura continua.
E continua funcionando.
Talvez esta seja uma das maiores demonstrações da elegância da engenharia IBM.
Easter Egg Mainframe
Alguns desenvolvedores chamavam aplicações conversacionais de:
Programas preguiçosos.
Porque passavam a maior parte do tempo...
Esperando o usuário pensar.
Enquanto os programas pseudo-conversacionais eram apelidados de:
Programas ninja.
Aparecem.
Executam.
Desaparecem.
Voltam.
Executam.
Somem novamente.
Tudo em poucos milissegundos.
Continua...
Na Parte 2 veremos:
✔ Problemas clássicos do modelo conversacional;
✔ Deadlocks de recursos;
✔ Pseudo-conversação com múltiplas telas;
✔ COMMAREA versus Channels e Containers;
✔ Web Services no CICS;
✔ REST, SOAP e z/OS Connect;
✔ Exemplos COBOL completos;
✔ Boas práticas;
✔ Troubleshooting;
✔ Curiosidades e easter eggs pouco conhecidos do universo CICS.
Sem comentários:
Enviar um comentário