INFRAESTRUTURA DE

CICS
“Tudo o que você sempre quis saber
sobre CICS, mas nunca teve a
coragem de perguntar.”
Maiores Consumidores
UNIDADE 1 – Customer Information Control System - CICS
 Introdução ao CICS TS

Customer Information Control System

 O que é CICS ?

• O CICS é um sistema de gerenciamento de transações ONLINE, que pode ser usado em

uma variedade de sistemas operacionais. Por exemplo: Z/OS, VSE, UNIX, Windows e
outros.

• O CICS fornece aos usuários de um aplicativo ONLINE, acesso aos dados de forma
rápida, eficiente e segura.

• O CICS pode ser classificado como um “middleware”, ou como um “Servidor de

Aplicativos” às aplicações do usuário.
 O que ele faz ?

• Gerencia a interface dos aplicativos com o Usuário.

• Recupera e modifica dados (VSAM, DB2).
• Controla o acesso aos dados locais (VSAM).
• Suporte à definição e uso de recursos (transações, programas, arquivos, conexões, etc.).
• Interface com software de segurança (RACF).
 BATCH x ONLINE

Processamento Transação Online

Batch (OLTP)
Agendado para um horário específico. Iniciado pelo usuário final quando o
Utiliza Job Control Language. serviço é solicitado.
Programa de entrada executa um lote de A entrada é fornecida pelo usuário final
transações. em um único pedido.
Saída demorada. Saída imediata.
O programa, geralmente, tem o controle O arquivo é compartilhado. O programa
exclusivo do arquivo. tem o controle exclusivo do registro.
 Pseudo-conversacional

Após enviar a resposta ao usuário (SEND), o programa termina através do comando

RETURN, encadeando uma nova execução da mesma transação – TRANSID (‘FAT1’).
Isso significa que a task terminará, os recursos serão liberados, mas quando o usuário
teclar ENTER, PFs, PAs, ou CLEAR, uma nova task da mesma transação será
executada. Portanto, o usuário terá a sensação de uma conversação, mas estará
ocorrendo uma pseudo-conversação.
 Características de uma Transação Comercial
• Muitos usuários – Normalmente, a maioria
das pessoas em uma organização executam
transações que contribuem para os resultados
dos negócios.
• Repetitiva – A maioria das interações com o
computador, tendem a ser o mesmo processo
executado várias vezes, por exemplo, o
registro de pedidos.
• Pequenas Interações – A maioria das
interações são de curta duração, por
exemplo, uma consulta do saldo de uma conta
corrente.
• Dados Compartilhados – Uma vez que os
dados representam o estado atual da
organização, só pode haver uma cópia deles
sendo acessados por vários usuários.
• Integridade dos Dados – Os dados devem ser
consistentes.
• Baixo custo / Transação – Se o processamento
das transações representa um custo direto do
negócio, esse custo deve ser minimizado ao
máximo.
Exemplos de aplicações comerciais
 Requisitos de uma aplicação de negócio
Aplicações ONLINE têm requisitos complexos porque executam em
um ambiente compartilhado entre vários usuários. A fim de
atender a essas necessidades, elas devem tratar as seguintes
questões:

• Bloqueio de recursos para evitar atualizações simultâneas.

• Manipulação de condição de exceção, de tal forma que não afete
todo o sistema.
• Schedulagem de várias transações que executem simultaneamente.
• Garantia de que apenas usuários autorizados acessem o sistema.
• Emissão de comandos de comunicação com SGBD´s

No entanto, se essas funções devem estar combinadas com a lógica

de negócio, ou seja, se os programas do aplicativo devem
implementar essas funcionalidades além da própria lógica do
negócio, torna-se uma missão muito difícil.
 Funções do Servidor de Aplicações
Em vez de exigir que os desenvolvedores escrevam funções
do S.O. em seus aplicativos, o CICS executa esses serviços
automaticamente ou a pedido dos programas. São várias
as vantagens:

• Redução no tempo de desenvolvimento.

• Mais fácil incorporar novas funções do S.O.
• Manutenção mais fácil.
• Infraestrutura consistente para todas as aplicações.

Essas abordagens permitem que o desenvolvedor se

concentre na resolução de problemas do negócio, em vez
das funções executadas pelo S.O.
 CICS – Gerenciador de Serviços
Aplicações CICS realizam as seguintes ações:

• Recebem uma solicitação de serviço.

• Acessam um arquivo ou banco de dados.
• Enviam uma resposta.

O CICS disponibiliza uma série de funções de gestão para

apoiar esses aplicativos, similares aos serviços prestados
pelo S.O.:

• Interface de comunicação com os vários mecanismos de

comunicação / transporte.
• Realiza a autenticação de usuários e recursos de segurança,
chamando componentes externos, como o RACF.
• Prevê a execução simultânea ou multi tasking, usando o
Dispatcher.
 Serviço de Comunicação

O Communication Service gerencia toda a comunicação com

o mundo externo.

A figura mostra a evolução do CICS ao longo do tempo, a

partir do terminal 3270 até o mais recente Web Service.

Caso você esteja se perguntando sobre o tipo de

comunicação “?!àéu$”, isso significa que o CICS vai sempre
se adaptar a qualquer novo protocolo de comunicação.
 Transações e Tasks
Uma aplicação CICS consiste em um ou vários programas
escritos para executar uma função específica.

Uma chamada a tal aplicação é conhecida como

TRANSAÇÃO e é identificada pelo CICS como TRANSID
(no máximo 4 bytes).

Quando o usuário starta uma transação, o CICS cria uma

TASK, que é a execução de uma aplicação para um
determinado usuário. Como mostra a figura, para cada
usuário, o CICS cria uma TASK diferente, mesmo se usam
a mesma TRANSID, ou seja, há uma transação mas duas
TASKS. Cada TASK é representada por um bloco de
controle, alocado na memória do CICS, que monitora a
execução dos programas associados a uma transação.
 Fluxo de uma Transação
Agora que você já compreende as funções de gestão do
CICS, vamos aprender como essas funções trabalham
juntas para processar uma transação, seguindo o fluxo de
uma transação CICS a partir de uma entrada pelo
terminal. Você aprenderá mais sobre cada componente
CICS.

Como mostra a figura, o CICS disponibiliza vários

componentes, alguns chamados diretamente pela aplicação,
e outros chamados pelo gerenciador para atender a uma
necessidade da sua aplicação.

Muitos componentes mostrados aqui são opcionais.

 Multitasking
A fim de proporcionar um tempo de resposta rápido para a
aplicação, um único CICS deve ser capaz de processar os
trabalhos de vários usuários simultaneamente.
Este é um trabalho do Dispatcher do CICS. Ele funciona
como um sistema operacional.
Neste exemplo:
• TASK1 requisita que o programa seja carregado, então o
Program Manager coloca a task em WAIT até que esse
evento processe.
• O Dispatcher localiza a TASK2, que estava esperando, e
passa o controle para ela.
• TASK2 emite um comando de leitura de um arquivo, então
o File Manager coloca a task em WAIT até que a operação
complete.
• O Dispatcher verifica que a carga do programa solicitado
pela TASK1 está completo, então, entrega o controle para
ela.
 Término da TASK

Depois de enviada a mensagem de resposta, o programa

não tem mais nada a fazer, então ele irá emitir o comando
de encerramento.

Neste momento, o CICS libera todas as áreas de memória

relacionadas com a task. O eficiente “Garbage Collector
(coletor de lixo)” do CICS, recupera essas áreas.
Address Space na arquitetura Z
 Chave de Proteção de Memória

Uma Chave de Memória (storage key) é associada com cada bloco de 4 KB de memória. A chave de memória tem 7 bits, sendo:

• Access-Control Bits, com 4 bits, que é a Chave de Proteção, e provê a proteção de memória;
• Fetch-Protection Bit, controla se a proteção se aplica a referências do tipo fetch (busca);
• Reference Bit, indica se o bloco foi referido para leitura/gravação de informação;
• Change Bit, indica se informação foi armazenada/alterada no bloco correspondente.
 JES2
Address Space batch (initiator)

Execution queue

INIT 1 INIT 2 INIT 3

System Program Loader

RMODE 31 Módulo de carga

PSW KEY = 9

Bibliotecas ACC BITS=0 Área comum (acima da linha)

De
16 Mb
Módulos
De ACC BITS=0 Área comum (abaixo da linha)
carga

Módulo de carga
RMODE 24 PSW KEY = 9

ACC BITS=0 Área do Sistema Operacional

Composição da memória no Address Space do CICS
(Dynamic Storage Area)
Barra 2 GB

FREE POOL

Above
EUDSA
ERDSA
ESDSA
ECDSA

Line 16 MB
FREE POOL

UDSA Below

RDSA
SDSA
CDSA
 Execução de um programa COBOL
(Reentrante)

RDSA UDSA

TRANID TSTA
1
PGM TESTEA

WS
TESTEA

WS WS
TRANID TSTB
2 TESTEA TESTEB
PGM TESTEB

TRANID TSTA
3 Código Código
PGM TESTEA
TESTEA TESTEB
DFHRPL
 CEMT
T01
WB01 WB02 PCT Transações
WB01
PROG01 PROG02 PPT Programas

DFHCSD FCT FILES (Arquivos)

T02

WB01 VTAM T01 T02 T03 TCT Terminais

RDSA COBOL
T03
PROG01 PROG02 Identification
WB02 1100101001001001001
0010000011101100110
0111001111011110011
0101011111100001101
Environment
0001100101101010010 0001110101011010101 Data
Procedure

UDSA
INSTALL
JOB Batch

CEDA TASKID01

TCA
TASKID02

TCA
TASKID03

TCA NEW COPY - TRN

- COB
- LKDE
(BINDER)

DFHCSD LOAD MODULES

TRANSACTION PROGRAM
PROG01 PROG02
1100101001001001001 0111001111011110011
WB01 - PROG01 PROG01 0010000011101100110 0101011111100001101
WB02 - PROG02 PROG02 0001100101101010010 0001110101011010101
 Execução concorrente de tasks

Como dissemos, para cada execução de transação (task), é criado um bloco de controle
chamado TCA. Portanto, se tivermos várias tasks da mesma transação, teremos várias
TCAs, uma para cada task. Entretanto, o CICS não carrega na memória várias cópias
de um mesmo programa. Apenas uma cópia do programa é carregada e utilizada por
todas as tasks. Tem que ter uma cópia da WORKING-STORAGE para cada task, já que
ela é utilizada com dados diferentes para cada usuário.

A TCA é o ponto focal da task, já que todas as áreas são encadeadas a partir dela. Cada
task terá também uma área denominada EIB (Exec Interface Block), que traz uma série
de informações muito úteis para nossos programas.
 Exec Interface Block (EIB)
O EIB (Exec Interface Block) é uma área que fica na LINKAGE SECTION de nosso programa e traz uma série de
informações que podem e devem ser utilizadas a qualquer momento para facilitar nosso trabalho. Abaixo, estão algumas das
informações que constam do EIB.

EIBTIME - Hora
EIBDATE - Data
EIBSPOSN- Posição do Cursor
EIBAID - Tecla pressionada (Enter, PF2, PF3, etc.)
EIBCALEN - Tamanho da Commarea
EIBTRNID - Código da Transação
EIBTRMID - Terminal associado
EIBFN - Última função executada
EIBRESP - Response Code
 Executando Transações

Quando o usuário chama uma transação a partir de um terminal conectado ao CICS,

imediatamente é verificado se essa transação está cadastrada na tabela PCT. Se estiver,
um bloco de controle denominado TCA (Task Control Area) é criado e vai existir
durante a execução da task.

Através da PCT o CICS sabe qual o programa associado à transação, e verifica se esse
programa está cadastrado na tabela PPT (Processing Program Table). Se estiver tudo
o.k., a task é executada.
Execução de um programa COBOL
(Storage Violation)

UDSA

H WS1 T H WS2 T H WS3 T

Execução de um programa COBOL
(Storage Protect)

Address space CICS

FREE POOL

EXTENT DA ECDSA

EUDSA H T

ERDSA

ESDSA

ECDSA
 A comunicação entre CICS

Podemos ter uma única região de CICS se tivermos uma carga de trabalho pequena,
mas caso a empresa tenha um alto número de usuários e muito processamento online a
ser executado diariamente, podemos ter diversas regiões CICS trabalhando e
distribuindo a carga através de facilidades de comunicação.

Um CICS pode comunicar-se com outros CICS residentes na mesma CPU, em CPUs
diferentes e mesmo em localidades diversas do planeta, facilitando muito o
processamento distribuído.
 Passagem de dados para a próxima task - COMMAREA

Para enviar dados para a próxima task, podemos utilizar uma área de
comunicação chamada COMMAREA. Essa área será passada através de uma área de
WORKING-STORAGE no programa e pode ter qualquer nome. Na próxima execução,
os dados passados serão recebidos em uma área reservada do programa, localizada na
LINKAGE SECTION e chamada DFHCOMMAREA (nome reservado). A área
transmitida deve ter o mesmo tamanho em sua recepção na DFHCOMMAREA.

Na primeira execução da transação não podemos utilizar a DFHCOMMAREA, pois

ela ainda não existe. Ela existirá a partir da segunda execução, com os dados recebidos.
Como saberemos se estamos processando a transação pela primeira vez? A resposta
para esta importante questão está em um campo do EIB denominado EIBCALEN
(Commarea Length). Na primeira execução da transação, o EIBCALEN estará com valor
zero, e nas demais execuções estará maior que zero.
 Passagem de dados para a próxima task - CONTAINER

Um CONTAINER é uma referência nomeada a uma área de armazenamento sob

gerenciamento do CICS (CICS-management storage area) que pode conter qualquer tamanho e
qualquer tipo de dados da aplicação. Uma aplicação pode referenciar qualquer número de
CONTAINERS. A EXEC API do CICS provê instruções para criar, apagar, referenciar,
acessar e manipular um CONTAINER como também para associa-lo a um CHANNEL (canal).

Um CHANNEL é uma referência única nomeada para uma coleção de dados de parâmetros
de uma aplicação disposta em CONTAINERS.

CHANNEL01

CONT01 CONT03 CONT05

CONT02 CONT04 CONT06

 Conversacional x Pseudo-conversacional

Existem duas formas de programação sob CICS:

Conversacional: é uma técnica antiga que praticamente não está sendo utilizada,
uma vez que consome muitos recursos do sistema, e vai contra a filosofia do CICS,
que é de aplicações que processem rapidamente e consumam poucos recursos. Essa
técnica consiste em processar os dados recebidos do usuário, devolver a resposta, e
aguardar para receber novas solicitações.

Pseudo-Conversacional: é a técnica mais utilizada, mais moderna e mais eficiente de

programação. A aplicação recebe a solicitação do usuário, processa, envia a resposta
e termina, liberando praticamente todos os recursos. Ao terminar, a aplicação
encadeia uma nova execução da transação, como veremos a seguir.
UNIDADE 2 – Comunicação entre Programas
 Controle de Programas

Veremos agora os comandos de transferência de controle entre programas em uma

mesma task.

CICS: LINK e XCTL

COBOL: CALL estático e dinâmico

Veremos também como é feita a passagem de dados entre programas.

 LINK entre Programas

O comando LINK passa o controle para o programa indicado. Esse programa executa
e, ao terminar, devolve o controle ao programa que emitiu o LINK (chamador).

Os dois programas são executados sob a mesma TASK.

 Passagem de dados usando o LINK

Assim como na pseudo-conversação, também utilizamos a COMMAREA ou

CONTAINER para passagem de dados entre os programas no comando LINK.

No caso da passagem utilizando a COMMAREA, o programa chamador passa uma

área da WORKING-STORAGE. O programa que recebe o controle (chamado) vai
acessar os dados passados através da DFHCOMMAREA em sua LINKAGE SECTION.

Se os dados recebidos na DFHCOMMAREA pelo programa chamado forem alterados,

quando esse terminar e o controle voltar para o programa chamador, a área da
WORKING-STORAGE que foi passada como COMMAREA também estará alterada.

Os dois programas devem estar definidos na PPT do CICS.

 Níveis Lógicos - LINK

NÍVEL 0 CICS

Primeiro Programa

NÍVEL 1

LINK
.....
RETURN

Segundo Programa
NÍVEL 2
.....
RETURN
 Níveis Lógicos - LINK

Todo programa chamado pelo LINK executa em novo nível lógico. Quando termina (RETURN),
o controle volta para o nível lógico imediatamente superior, ou seja, para o programa que
emitiu o LINK ou, no caso do primeiro programa, para o CICS.

Primeiro Programa – PROG01 Segundo Programa – PROG02

WORKING-STORAGE SECTION. WORKING-STORAGE SECTION.

01 W-COMM PIC X(03) VALUE ‘SIM’. 01 W-FLAG PIC X(03) VALUE ‘NAO’.
....... LINKAGE SECTION.
PROCEDURE DIVISION. 01 DFHCOMMAREA.
EXEC CICS LINK PROGRAM(‘PROG02’) 02 L-COMM PIC X(03).
COMMAREA(W-COMM) .......
LENGTH(LENGTH OF W-COMM) PROCEDURE DIVISION.
END-EXEC. MOVE W-FLAG TO L-COMM.
...... EXEC CICS RETURN END-EXEC.
DISPLAY W-COMM.
 XCTL entre programas

O comando XCTL também passa controle para outro programa, mas ao contrário do LINK,
quando o programa chamado termina, o controle não retorna ao programa chamador. O XCTL
é muito utilizado para desenvolver MENUS de aplicações.

A passagem de dados entre programas é exatamente igual ao LINK. Pode-se utilizar a

COMMAREA ou CONTAINER.
 Níveis Lógicos - XCTL

NÍVEL 0 CICS

Primeiro Programa Terceiro Programa

NÍVEL 1
.....
LINK RETURN
.....
XCTL
.....
NÍVEL 2 RETURN

Segundo Programa
.....
RETURN
 CALL estático

CALL literal: CALL ‘PROG02’.

Algumas considerações:

•Apenas um módulo executável. Os programas “chamador” e “chamado” são linkeditados

(binded) como um único módulo executável.
•Do ponto de vista de performance, é uma boa opção, uma vez que não ocorrerá a carga do
programa chamado na memória.
•Por outro lado, se diversos programas fizerem CALL para esse mesmo programa, teremos
diversas cópias dele na memória.
•Outro ponto a considerar, é o fato de ser mais difícil a determinação de problemas no caso de
um ABEND.
 CALL dinâmico

MOVE ‘PROG02’ TO W-PROG.

CALL variável: CALL W-PROG.

Algumas considerações:

• Os programas “chamado” e “chamador” são linkeditados (binded) separadamente, sendo dois

módulos executáveis distintos.
• Quando for feito um CALL, o programa “chamado” será carregado em memória e executado.
• Se diversos programas fizerem um CALL para esse mesmo programa, teremos apenas uma
cópia em memória.
UNIDADE 3 - Filas
 QUEUEING
Nessa unidade veremos os comandos necessários para trabalhar com as duas facilidades que o
CICS oferece para armazenamento temporário de dados (enfileiramento de dados): Transient Data
(TD) e Temporary Storage (TS).
 TRANSIENT DATA - TD
As filas de Transient Data são identificadas por um nome de 4 caracteres cadastrado na tabela DCT (Destination Control Table) e
conhecido como DESTID (Destination ID).
O CICS oferece dois tipos de TD: intrapartition e Extrapartition.

TD Intrapartition:

• Todas as filas de TD são direcionadas para o mesmo arquivo VSAM ESDS chamado DFHINTRA;
• Os registros nas filas são gravados sempre sequencialmente e recuperados da mesma forma;
• A leitura é destrutiva, ou seja, uma vez lido não pode ser recuperado novamente;
• Os registros podem ter tamanho variável.

TD Extrapartition: É a forma que o CICS oferece para utilizarmos arquivos SAM (Sequential Access Method).

• Cada fila TD corresponde a um arquivo físico;

• A leitura não é destrutiva, pois podemos ler o mesmo registro várias vezes;
• Não podemos fazer exclusão;
• Os registros podem ter o tamanho fixo ou variável, blocado ou não blocado;
• Cada fila pode ser definida como INPUT ou OUTPUT, nunca como INPUT e OUTPUT.
 Gravação de TD
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
01 W-DADOS.
03 W-NOME PIC X(40).
03 W-TELEFONE PIC X(09).
*
PROCEDURE DIVISION.
MOVE ‘PAULA TOLLER’ TO W-NOME.
MOVE ‘3104-9999’ TO W-TELEFONE.
*
EXEC CICS WRITEQ TD QUEUE(‘TD01’)
FROM(W-DADOS)
LENGTH(LENGTH OF W-DADOS)
END-EXEC.

O comando WRITEQ TD é utilizado para gravação de TD´s Intrapartition e Extrapartition.

 Leitura de TD
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
01 R-DADOS.
03 R-NOME PIC X(40).
03 R-TELEFONE PIC X(09).
*
PROCEDURE DIVISION.
EXEC CICS READQ TD QUEUE(‘TD01’)
INTO(R-DADOS)
LENGTH(LENGTH OF R-DADOS)
END-EXEC.

O comando READQ TD é utilizado para leitura de TD´s Intrapartition e Extrapartition.

EXEC CICS DELETEQ TD QUEUE(‘TD01’) END-EXEC.

O comando DELETEQ TD aplica-se, apenas, às TD´s Intrapartition. Este comando exclui

todos os registros de uma fila TD.
 TEMPORARY STORAGE - TS
A Temporary Storage (TS) tem nomes de 1 a 8 caracteres, e não necessita que esses nomes sejam
pré-definidos em tabelas do CICS. Se a fila não existir, ela será criada no primeiro comando
WRITEQ TS.

• As filas TS podem ser gravadas em disco (AUX) ou em memória (MAIN), onde o acesso é muito
mais rápido;
• Os registros (itens) podem ter o tamanho fixo ou variável;
• A TS aceita gravação sequencial, leitura sequencial e direta, e atualização;
• Os dados permanecem disponíveis até que sejam excluídos por comando, ou enquanto o CICS
estiver ativo.
 Gravação de TS
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
EXEC CICS WRITEQ TS QUEUE(name)
FROM(data-area)
[LENGTH(LENGTH OF data-area)]
[ITEM (data-area)[REWRITE]]
[MAIN | AUXILIARY]
END-EXEC.

O comando WRITEQ TS é utilizado para gravação de TS´s.

• As opções MAIN e AUX determinam se a fila será gravada em memória ou disco;

• Quando estivermos gravando, se codificarmos a opção ITEM, o CICS retorna o número
(posição) desse item na fila;
• Se codificarmos as opções ITEM e REWRITE, o CICS fará atualização do item indicado
com o novo conteúdo.
 Gravação de TS
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
01 W-ITEM PIC S9(04) COMP.
01 TS-REG.
. . .
PROCEDURE DIVISION.
*
EXEC CICS WRITEQ TS QUEUE(‘FATTS01’)
FROM(TS-REG)
LENGTH(LENGTH OF TS-REG)
ITEM (W-ITEM)
END-EXEC.

O comando acima grava um item na fila TS FATTS01.

MOVE ’10’ TO W-ITEM.

EXEC CICS WRITEQ TS QUEUE(‘FATTS01’)
FROM(TS-REG)
LENGTH(LENGTH OF TS-REG)
ITEM(W-ITEM)
REWRITE
END-EXEC.

O exemplo acima mostra a atualização do item 10 da fila TS FATTS01.

 Leitura de TS
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
EXEC CICS READQ TS QUEUE(name)
INTO(data-area)
[LENGTH(LENGTH OF data-area)]
[ITEM (data-area)[NEXT]]
[NUMITENS(data-area)]
END-EXEC.

O comando READQ TS é utilizado para leitura de TS´s.

• A opção NEXT indica que estamos fazendo leitura sequencial da fila;

• Se utilizarmos a opção ITEM estaremos fazendo leitura direta;
• Se a opção NUMITENS for codificada, o CICS informa o número total de itens na fila.
• As data-areas dos campos ITEM e NUMITENS devem ser codificadas com PIC S9(04
COMP.
 Leitura de TS
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
01 W-ITEM PIC S9(04) COMP.
01 TS-REG.
. . .
PROCEDURE DIVISION.
*
MOVE ’10’ TO W-ITEM.
EXEC CICS READQ TS QUEUE(‘FATTS01’)
INTO(TS-REG)
LENGTH(LENGTH OF TS-REG)
ITEM (W-ITEM)
END-EXEC.

O comando acima lê o item 10 na fila TS FATTS01.

EXEC CICS DELETEQ TS QUEUE(‘FATTS01’) END-EXEC.

O comando acima exclui a fila TS FATTS01.

UNIDADE 4 - Exceções
 Manuseio de Exceção
É de extrema importância o manuseio de condições de exceção em programas executando sob CICS. Uma das
técnicas é a chamada técnica estruturada, codificando-se a opção RESP nos comandos e em seguida testando o
campo utilizado como argumento.

....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
01 RESP1 PIC 9(05).
01 RESP2 PIC 9(05).
01 W-DADOS PIC X(50).
*
PROCEDURE DIVISION.
EXEC CICS READQ TS QUEUE(‘FATTS01’)
INTO(W-DADOS)
LENGTH(LENGTH OF W-DADOS)
RESP(RESP1)
RESP2(RESP2)
END-EXEC.
IF RESP1 NOT EQUAL DFHRESP(NORMAL)
GO TO ROTINA-TRATA-ERRO.
. . . . .
ROTINA-TRATA-ERRO.
. . . . .
 Manuseio de Exceção
Manuseio de condições de exceção

EXEC CICS HANDLE CONDITION

Condition(label)
Condition(label)
.....
EXEC CICS IGNORE CONDITION
Condition
Condition
.....
O comando HANDLE CONDITION serve para deixarmos pré-estabelecidas as rotinas para
manuseio de condições de exceção. Podemos especificar até 16 condições, e ao executar um
comando, se a condição ocorrer será feito um desvio automático para a rotina especificada no
HANDLE CONDITION.

O comando IGNORE CONDITION serve para o CICS ignorar as condições especificadas, e deixar
o programa continuar. Serve também para resetar condições tratadas anteriormente em
HANDLE CONDITION.
 Manuseio de Exceção
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
PROCEDURE DIVISION.
EXEC CICS HANDLE CONDITION
INVREC(TRATA-INV)
LENGERR(TRATA-LENGERR)
NOTFND(TRATA-NOTFND)
PGMIDERR(TRATA-PGMIDERR)
ERROR(TRATA-ERROR)
END-EXEC.
EXEC CICS IGNORE CONDITION
INVREQ
END-EXEC.
EXEC CICS READ FILE(‘KZF001’)
RIDFLD(W-CHAVE)
INTO(W-REG)
END-EXEC.
. . . . . . .
TRATA-NOTFND.
. . . . . . .
TRATA-LENGERR.
. . . . . .
 Opções para manuseio de exceções
Uma das maneiras de tratar as condições de exceção é codificar a opção RESP, e em seguida
testar o campo utilizado como argumento.

Outra forma estruturada de trabalhar é codificar a opção NOHANDLE nos comandos. O CICS
deixará o programa prosseguir, e devemos testar o campo EIBRESP.

A utilização de HANDLE e IGNORE CONDITION quebra a estrutura do programa, por tanto, não
é aconselhável.

Se não utilizarmos nenhuma das condições mostradas acima, no caso de exceções, o CICS toma
uma ação “default”, que geralmente é ABENDAR a task.
 Manuseio de Teclas
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
WORKING-STORAGE SECTION.
. . . .
COPY DFHAID.
PROCEDURE DIVISION.
EVALUATE EIBAID
WHEN DFHPF3
GO TO ROTINA-SAIDA.
WHEN DFHENTER
GO TO ROTINA-GRAVACAO.
WHEN DFHPF6
GO TO ROTINA-LIMPA-CAMPOS
WHEN OTHER
MOVE ‘Tecla Inválida.’ TO MSG
GO TO ROTINA-ERRO
END-EVALUATE.

Para testar qual tecla foi pressionada pelo usuário, vimos a técnica estruturada, que consiste em
copiar o copybook DFHAID na WORKING-STORAGE, e depois testar o campo EIBAID. Essa é a
técnica recomendada.
 Cuidado ao utilizar HANDLE
Se o CICS detecta uma tecla controlado por HANDLE AID e uma condição de exceção controlada
por HANDLE CONDITION após um comando de input, o desvio é feito para a rotina do HANDLE
AID.
Abaixo mostramos uma condição em que a tecla PF5 foi pressionada e um MAPFAIL ocorreu. O
desvio foi feito para a rotina TRATA-PF5.
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
PROCEDURE DIVISION.
EXEC CICS HANDLE CONDITION
MAPFAIL(TRATA-MAPFAIL)
NOTFND(TRATA-NOTFND)
LENGERR(TRATA-LENGERR)
END-EXEC.
. . . . .
EXEC CICS HANDLE AID
PF5(TRATA-PF5)
END-EXEC.
. . . . .
TRATA-MAPFAIL.
. . . . .
TRATA-NOTFND.
. . . . .
TRATA-PF5.
. . . . .
 Comando HANDLE ABEND
O comando HANDLE ABEND devolve o controle para o programa quando o CICS determina que
a transação deveria terminar de forma anormal. Dessa forma, o programa pode realizar um
“housekeeping” antes de seu término.

....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
PROCEDURE DIVISION.
EXEC CICS HANDLE ABEND
[PROGRAM(name)|
LABEL(label) |
CANCEL |
RESET]
END-EXEC.
UNIDADE 5 – Startup e Shutdown
 Data Sets de Startup e Shutdown

Uma mostra dos Data Sets e as principais informações necessárias

para iniciar e terminar uma Region CICS, são:
• As bibliotecas de instalação do produto fornecidas pela IBM (´núcleo
do CICS)
• A tabela DFHSIT que contem os parâmetros de inicialização do
CICS. Pode-se trabalhar com várias tabelas SIT.
• A fim de simplificar a administração, os parâmetros da SIT podem ser
OVERRAIDADOS a partir do parâmetro SYSIN. Os parâmetros
comuns a todos os CICS, devem estar na tabela SIT, enquanto os
parâmetros especìficos de cada CICS devem ser especificados no
parâmetro SYSIN
• O Data Set de Catálogo do CICS contém informações necessárias
para a inicialização do sistema. Por exemplo, se o processo de
encerrameno anterior ocorreu sem problemas.
• Se o backout é necessário, o CICS utilizará as informações contidas
no arquivo de LOG
 Start inicial do CICS

A primeira vez que uma Region CICS é inicializada, deve-se

executar um INITIAL STARTUP.

O CICS reinicializa todos os seus Data Sets e instala todos os

recursos definidos em todos os GRUPOS definidos em todas as
LISTAS especificadas no parâmetro GRPLIST da SIT.

Ao final da inicialização, o CICS grava um EMERGENCY

RESTART REQUIRED (ou EMER, ou seja, encerramento
anormal) indicado no Data Set DFHGCD. Este indicador será
usado na inicialização do CICS para determinar se a
recuperação de recursos deve ser executada.
 Iniciando e Encerrando

Depois que o CICS é iniciado, seus Usuários executarão transações

que farão atualizações no CICS ou em recursos externos. O Gerente de
recuperação grava as informações de recuperação nos catálogos do
CICS e no SYSTEM LOG.

Quando os recursos são instalados pelo comando CEDA INSTALL ou

nas listas de inicialização (GRPLIST), o CICS grava uma cópia desses
recursos no catálogo global DFHGCD.

O Administrador do CICS, quando quer terminar uma Region do

CICS, normalmente, executa o comando CEMT PERFORM
SHUTDOWN. O CICS termina bem e “overraida” o indicador EMER
com um indicador WARM.

Em algumas raras ocasiões, o CICS será encerrado anormalmente.

 Shutdown Normal

A maneira recomendada para encerrar o CICS é usando o comando CEMT

PERFORM SHUTDOWN. Isto inicia o processo de encerramento do CICS,
que executa as seguintes etapas:
• Desativa o sistema permitindo que as transações existentes concluam
suas atividades. O objetivo é, progressivamente, concluir todas as TASKS
em execução.
• Programas especificados pelo usuário podem executar automaticamente,
a fim de fechar as conexões com bancos de dados ou realizar outras
tarefas
• O CICS coleta estatísticas sobre a utilização de inúmeros recursos. Estes
são gravados em meio externo. Os arquivos são fechados.
• Então, o CICS registra a situação dos recursos e define o registro de
controle no Global Catalog para indicar que um WARM START é
possível.

Finalmente, a mensagem “SHUTDOWN COMPLETE” é enviada para a

console do sistema e para o terminal que entrou com o comando de
desligamento.
 Shutdown Imediato

Às vezes, TASKS de longa duração não são encerradas com

o SHUTDOWN normal. Como mostrado aqui, você pode
“puxar a tomada” do CICS. Embora estatísticas sejam
gravadas, há desvantagens:

• Qualquer TASK em voo, não será concluída;

• Não haverá a oportunidade de executar programas do
Usuário;
• Não será possível fazer um WARM START na próxima
inicialização.
 Término descontrolado

Um desligamento descontrolado poderia ser resultado

de uma falha de energia, uma falha de Sistema
Operacional ou um erro do Operador.

Como do caso do SHUTDOWN IMEDIATO, o

indicador de WARM START não será setado, portanto,
a próxima inicialização executará um EMERGENCY
RESTART para fazer o BACKOUT das unidades de
trabalho incompletas.
 Opções de Startup

START=AUTO prevê WARM ou EMERGENCY restart, dependendo

da configuração do indicador de reinício.
O CICS toma a decisão verificando o registro de controle no Global
Catalog.
Se a execução anterior do CICS terminou normalmente, esse registro
indica que um WARM START é possível, e o status dos recursos do
CICS serão recuperados a partir do Global Catalog.
No entanto, se o CICS não terminar normalmente, o registro diz que
um EMERGENCY RESTART é necessário. Neste caso, o CICS faz o
BACKOUT das unidades de trabalho incompletas.
Em ambos os casos, os recursos são construídos a partir do Global
Catalog ao invés de usar a lista de grupos e da definição do sistema de
arquivos do CICS.
Se não há nenhum indicador no DFHGCD, o CICS, automaticamente,
executa um START INITIAL.
 COLD Restart

Um COLD START é semelhante a um INITIAL START: ele

carrega as definições de recursos do DFHCSD e ignora as
informações do System Log a respeito do status dos recursos,
mas preserva todas as informações necessárias para voltar a
sincronizar com parceiros remotos.
 WARM Restart

Como foi mostrado, a única vez que o CICS reinicia com

WARM, é quando existe o parâmetro START=AUTO, na SIT,
e o indicador de WARM RESTART está setado no DFHGCD.

No encerramento normal, o CICS salva o status dos seus

recursos no DFHGCD. No WARM Restart, os recursos são
instalados a partir do DFHGCD e não do DFHCSD, como é o
caso do INITIAL e COLD Restart.
 EMER Restart

Quando o CICS não encerrou normalmente por causa de um

CEMT PERFORM SHUTDOWN IMMEDIATE (CEMT P
SHUT I), ou interrupção do sistema, todos os recursos devem
ser recuperados, a fim de manter a integridade do sistema e dos
dados.
O BACKOUT dos recursos é executado utilizando o Log do
sistema.
As definições dos recursos CICS são restauradas a partir do
DFHGCD (como o WARM Restart, não usa o DFHCSD).
Considerando que um WARM Restart restaura o status dos
recursos CICS, o EMER Restart não faz.
 Restart Emergencial: Backout

O objetivo do processo de Emergency Restart, é fazer

o BACKOUT das unidades de trabalho que estavam em
voo no momento do encerramento do CICS.
Para se preparar para o BACKOUT, o CICS primeiro
deve recolher todos os registros de logs anteriores e
copiar os registros BACKOUT das tasks que não
comitaram suas alterações. Este processo termina
quando todas as tasks em voo são contabilizadas. Para
encurtar esse processo, o CICS grava periodicamente
um registro de keypoint no log. Este registro contém o
task number de todas as tasks em voo neste momento.
UNIDADE 6 – CICS Data Sets
 CICS DATASETS

Para o seu correto funcionamento, o CICS necessita necessáriamente de alguns datasets que, com
exceção do DFHCSD, devem ser declarados na sua procedure de STARTUP.
 CICS DATASETS ( DFHCSD )

O dataset DFHCSD (CICS System Definition) é um

arquivo VSAM que funciona como repositório das
definições dos recursos necessários ao CICS. É um
dataset obrigatório e pode ser definido tanto na
procedure de STARTUP quanto no parâmetro CSDDSN
da SIT, sendo que, se definido na procedure, sobrepõe o
especificado na SIT. Existem outros parâmetros na SIT
que dizem respeito às caracteristicas de operação deste
dataset. Este dataset pode ser compartilhado por todas
as Regions CICS de um mesmo SYSPLEX.
 CICS DATASETS ( DFHCSD – SIT parms)

CSDACC = {READWRITE | READONLY}

Indica o tipo de acesso à CSD permitido na Region CICS

CSDBUFND = number
Especifica o número de buffers a serem utilizados para a área de dados do CSD. Este valor deve ser
definido tendo como base o parâmetro CSDSTRNO mais um. É ignorado caso tenha sido especificado o
parâmetro CSDLSRNO diferente de NONE

CSDBUFNI = number
Especifica o número de buffers a serem utilizados para a área de índice do CSD. Este valor deve ser
definido tendo como base, pelo menos, o valor definido para o parâmetro CSDSTRNO. É ignorado caso
tenha sido especificado o parâmetro CSDLSRNO diferente de NONE.
 CICS DATASETS ( DFHCSD – SIT parms)

CSDDISP = OLD|SHR}
Especifica a disposição do dataset. OLD significa sem compartilhamento e SHR com
compartilhamento de uso por outras Regions CICS;

CSDDSN = nome
Especifica o nome do dataset VSAM. Caso seja definido na procedure de STARTUP, este parâmetro é
ignorado;

CSDRLS = {NO|YES}
Especifica se o dataset VSAM é RLS ou não;

CSDSTRNO = number
Especifica o número de usuários concorrentes no acesso ao dataset.
 CICS DATASETS (DFHxUXT)

Os datasets de Auxiliary Trace são utilizados para coletar dados de trace para possibilitar a análise e
determinação de problemas no sistema.
 CICS DATASETS (DFHDMPx)

Os datasets de DUMP Trace são utilizados para armazenar dumps de transações para possibilitar a
análise e determinação de problemas nas transações.
 CICS DATASETS (DFHGCD/DFHLCD)

Enquanto o CICS está em execução, várias informações referente àquela execução são gravadas no
GLOBAL CATALOG e LOCAL CATALOG.
UNIDADE 7 – CICS Control Blocks
 CICS CONTROL BLOCKS (CSA)

A CSA (Common System Area) é o bloco de controle base

de uma Region CICS. Contém informações e ponteiros para
outros blocos de controle. O layout desse bloco de controle é
detalhado no Data Areas do CICS no capítulo CSA –
Common System Area generator.
CICS CONTROL BLOCKS (CSA)
 CICS CONTROL BLOCKS (TCA)

TCA (Task Control Area). Para cada task CICS em

execução, é criado este bloco de controle, que armazena
todas as informações pertinentes a esta execução. Contém
em sua estrutura o endereçamento para o bloco de controle
EIS (Execution Interface Structure) que por sua vez
endereça o bloco de controle EIB (Exec Interface Block).
Este bloco de controle representa a task junto ao Application
Domain.
CICS CONTROL BLOCKS (TCA)
CICS CONTROL BLOCKS (TCA)
 CICS CONTROL BLOCKS (EIS)

EIS (Exec Interface Storage). Este bloco de controle é a

ionterface entre o programa de aplicação e os blocos de
controle do CICS.
CICS CONTROL BLOCKS (EIS)
 CICS CONTROL BLOCKS (EIB)

EIB (Exec Interface Block). Este bloco de controle contém informações úteis ao programa durante a
sua execução, tais como: nome da transação, data e hora, terminal associado, número da task, última
tecla pressionada, posição do cursor, última API utilizada, etc.
 CICS CONTROL BLOCKS (CWA)

CWA (Commom Work Area). É um bloco de controle

único que é alocado em tempo de STARTUP do CICS e
permanece até o final da execução. Seu tamanho é
fixado no parâmetro WRKAREA da SIT. Pode ser
utilizado por qualquer programa em execução na
Region do CICS.
 CICS CONTROL BLOCKS (TWA)

TWA (Task Work Area). É um bloco de controle

de trabalho para a task. Seu tamanho é
especificado no parâmetro TWASIZE na definição
da transação.
 CICS CONTROL BLOCKS (TCTUA)

TCTUA (Termonal Control Table User Area). É

um bloco de controle para o terminal. Seu
tamanho é especificado no parâmetro
UserAreaLen, na definição do TypeTerm
 CICS CONTROL BLOCKS (TCB)

TCB (Task Control Block). São os blocos de

controle para administrar as TCBs do CICS.
Existe um paracada TCB atachada.
UNIDADE 8 – Transações Fornecidas
 Transações Fornecidas pelo CICS

As funções básicas das transações fornecidas pelo CICS

são de controle do sistema e recursos. Você utiliza essas
transações para:
• Examinar e alterar as tabelas que contém as definições
dos recursos;
• Alterar os parâmetros usados por alguns programas
CICS, por exemplo o número máximo de tasks
permitido;
• Testare programas e verificar mensagens;
• Executar ações de outros sistemas, como iniciar e parar a
conexão de bancos de dados.
 Transações Fornecidas pelo CICS

Aqui estão algumas das transações mais comuns do CICS:

• CESN/CESF – Permite você fazer o sign ON e sign OFF no
CICS;
• CEMT – Permite o controle dinâmico na verificação e mudança
do status dos recursos definidos;
• CEOT – Fornece informações do terminal e conversão de
caracteres maiúsculos;
• CMSG – Pode ser usado para enviar mensagens para um ou mais
destinos;
• CEDA – Cria e gerencia a definição de recursos;
• CEDB e CEDC – Fornecem um subconjunto da transação
CEDA;
• CEKL – Serve para “matar” transações penduradas no CICS;
• DSNC – Controla a interface do CICS com o DB2. Nos novos
releases, essa função também é suportada pelo CEMT.
 Transações Fornecidas pelo CICS

O CICS fornece várias operações úteis para testes de aplicativos:

• CMAC – Explica algumas mensagens e códigos de ABEND;

• CECI – Intérprete de Command-Level. Executa comandos de
programação digitados na tela;
• CEBR – Permite que você navegue e delete TS´s e TD´s;
• CEDF – O CICS Execution Diagnostic Facility, é usado para
testes e depuração de programas aplicativos, a partir de um
terminal;
• CEDX – Fornece depuração semelhante para transações não-
terminal.
UNIDADE 9 – Segurança
 Segurança no CICS

O CICS utiliza os serviços de um Gerente de Segurança externo, como

o RACF, para proteger seus recursos.
Você pode identidicar e autenticar usuários CICS usando credenciais
simples, como o userid ou sofisticadas, como as credenciais de
certificados digitais.
Você pode restringir o acesso a Region CICS de servidores remotos.
Você pode proteger as transações. Esse é o nível mais comum de
segurança no CICS.
Pode ser necessário um controle mais granular, por exemplo, você pode
permitir que muitos usuários acessem uma transação, mas apenas deixar
um subconjunto de usuários atualizarem os recursos CICS utilizados pela
transação.
A CEMT é uma transação muito perigosa. Você pode limitar o alcance
da transação usando a função de segurança de comandos, assim, por
exemplo, alguns usuários podem ficar limitados ao acesso read-only.
UseridA pode iniciar uma transação e associa-la a outro userid.
UseridB (conhecido como userid substituto).
 Autenticação

Numa configuração segura, a primeira coisa a faze é se autenticar para

o CICS. Existem diferentes formas de fazer a autenticação:
• Usando a transação CESN em um terminal 3270;
• Usando um certificado digital de um cliente a partir de um browser ou
um cliente HTTP em uma rede TCP/IP. Nesse caso, o certificado será
conectado a uma identificação de usuário usada, mais tarde, para
verificação de segurança.

Ao utilizar o VTAM, uma vez que o usuário foi autenticado, você pode
querer verificar se ele está autorizado a se conectar a uma Region CICS
específica.
Quando um servidor intermediário é usado para se conectar ao CICS,
como um outro sistema CICS, um WebSphere Application Server, ou um
front-end GUI, a autenticação pode ter sido feita a nível do sistema
intermediário. Se o servidor intermediário é confiável pelo CICS, a
informação de senha não será necessária
 Segurança das Transações

Uma vez que muitas aplicações diferentes costumam executar em

mesmo sistema CICS, a segurança é implantada, principalmente, a
nível de transações. Ou seja, alguns usuários terão acesso a diferentes
operações na mesma Region CICS.
O processo normal é o de autorizar um grupo de usuários a acessar
um determinado grupo de transações. Neste caso, o usuário
identificado como JANE está tentando executar a transação AP01. O
Gerente de segurança do CICS chama o Gerente de segurança
externo (RACF) para determinar se JANE está autorizada a executar
a transação AP01.
 Segurança dos Recursos

Para recursos diversos, por exemplo: arquivos, filas ou programas,

você pode executar a verificação de autorização a nível dos recursos.
Você solicita isso na definição da transação.
Neste exemplo:

JANE está autorizada a executar a transação AP01.

A definição da transação AP01 especifica que a verificação de
segurança dos recursos deve ser verificada (parâmetro
RESSEC(YES)).
O programa APADD faz uma solicitação de acesso a um recurso
do CICS. O CICS pede ao RACF para determinar se JANE tem
dreito de acesso a esse recurso. Por exemplo, se APADD emite uma
solicitação de atualização de um recurso do CICS e JANE só tem
acesso de leitura a ele, o pedido é negado e o CICS retorna um
NOTAUTH ao programa APADD.
 Segurança dos Comandos

Ao especificar CMDSEC(YES) na definição de uma

transação, você pode proteger determinados tipos de funções
de comandos do CICS. A principal utilização desta proteção,
é restringir o uso da transação CEMT. Por exemplo, o
CEMT permite inquirir sobre os recursos mas também
permite autera-los e dar um SHUTDOWN no CICS.
Se o usuário JANE é um programador, uma operação
normal seria usar o CEMT para executar a função NEW
COPY, a fim de testar um programa que tenha sido alterado
e recompilado.
No entanto, ela não tem permissão para usar o CEMT
para dar um SHUTDOWN no CICS.
UNIDADE 10 – CPSM (CICS Plex System Manager)
 CICSPLEX SYSTEM MANAGER (CPSM)

Permite que você gerencie um grupo de Regions CICS

como se fossem uma única entidade. O CPSM fornece um
único ponto de controle em que você emite comandos que
afetam todas as Regions CICS que compõem o CICSPLEX
da empresa, a partir de um Web browser.

Gerenciar um grande número de Regions CICS em uma

rede, pode ser uma tarefa muito difícil se tivermos que
utilizar as transações CEDA e/ou CEMT. O CPSM fornece
uma série de recursos para ajuda-lo a operar, controlar e
monitorar um complexo de sistemas CICS no Z/OS.
 Funções CPSM

O CPSM suporta quatro tipos de atividades de gerenciamento do

sistema:
• A função Operation Control permite controlar vários sistemas
CICS com um único comando, algo como uma operação CEMT
que afeta muitas Regions. Por exemplo, você pode dar um
SHUTDOWN em todas as Regions CICS ou atualizar um
programa (NEW COPY) em várias Regions.
• Business Aplications Services (BAS) permite você gerenciar a
definição de recursos em um grupo de Regions CICS,
assemelhando-se a transação CEDA, com um único comando.
• O CPSM provê a função Workload Management para
automatizar o roteamento de transações para o melhor
Application Owning Region (AOR), com o objetivo de
melhorar a performance.
• Threshold Analysis and Monitoring provê um feeadback em
tempo real e dados estatísticos das Regions selecionadas.
 Definição de Aplicações

Como mostra o gráfico, as Regions CICS podem compartilhar as

definições de recursos armazenados no repositório de dados do
CPSM, mesmo estando em processadores diferentes.

Sem um produto como o CPSM, várias Regions CICS na mesma

imagem Z/OS, geralmente compartilham a definição de recursos, mas
você tem que replicar para múltiplas imagens e instalar novas
definições em todas as Regions onde seja necessário.

Business Application Services (BAS), parte do CPSM, provê um

único ponto de controle para essas atividades. Para evitar a repetição
de definições para cada Region CICS, o BAS provê um conjunto de
comandos para criar definições de recursos no repositório de dados
do CPSM, em seguida, propaga essas definições para todo o
CICSPlex.
 Roteamento das Transações

SAÚDE
XX00 XX01 XX01 XX00

A01 70%
TOR A02 60%
T01 T02 T03
A03 75%
A04 50%
A05 30%
AOR A01 A02 A03 A04 A05

FOR F01 F02

VSAM01 VSAM02
DB2
 Roteamento das Transações

SAÚDE
XX00 XX01 XX01 XX00

A01 10%
TOR A02 80%
T01 T02 T03
A03 90%
A04 45%
A05 80%
AOR A01 A02 A03 A04 A05

FOR F01 F02

VSAM01 VSAM02
DB2
Interface do CPSM
Interface do CPSM
Interface do CPSM
Interface do CPSM
Interface do CPSM
Interface do CPSM
Interface do CPSM