CICS Resumo. Acerca deste resumo: Introdução (1-2) Arquitectura (3-4)

Transcrição

1 CICS Resumo Acerca deste resumo: Este é o resumo da matéria estudada para apresentar o sistema IBM CICS, o monitor transaccional mais utilizado. Cada secção diz respeito a um conjunto de acetatos que são indicados entre parêntesis. Introdução (1-2) A plataforma CICS (Costumer Information Control Service) apareceu como aplicação comercial em 1969, tendo acompanhado toda a evolução da computação em grande escala. Tendo a sua origem num sistema de mainframe monolítico (1-tier), evoluiu em seguida para o modelo cliente-servidor (2-tier), que foi o paradigma durante os anos 80 e parte dos anos 90. Com o advento de melhor hardware a mais baixo custo, as arquitecturas tornam-se mais distribuídas surgindo uma nova camada conceptual entre o cliente e o servidor. Esta ultima concepção deu origem a aplicações conhecidas como MiddleWare, que consistem na camada do meio. O sistema CICS adaptou-se à evolução e hoje é considerado uma plataforma MiddleWare. Apesar de ter vindo a perder segmento de mercado, mantém-se como líder, tendo como clientes 90% das 500 maiores empresas mundiais. Arquitectura (3-4) A arquitectura deste sistema, de uma forma geral, é semelhante a um sistema MiddleWare genérico, com aplicações Cliente que acedem a recursos de dados através de um MiddleWare que neste caso é o próprio sistema CICS.

2 figura 1: Arquitectura do sistema CICS. Uma região CICS é aonde os programas que compõe uma transacção correm. Existem tabelas, acessíveis em run-time, que referenciam programas, fontes de dados, e locais (outros sistemas CICS e outras aplicações) fora do sistema. Como componentes funcionais, em oposição aos componentes estruturais referidos na figura, temos: Clientes Clientes segundo o conceito comum do modelo cliente/servidor. O que invoca e inicia a conversação. Escalonador Transaccional Canaliza as transacções para os servidores transaccionais. Servidores Aplicacionais -Processos em tempo-real que correm os programas que compõem a transacção. Podem ser um ou mais, aspecto decidido na configuração do sistema. Servidor de Ficheiros Geralmente são SFS, structured file server, que permitem acesso aos dados de uma forma adaptada às necessidades de um monitor transaccional. A funcionalidade de um servidor de ficheiros pode ser substituída por uma Base de Dados Relacional. Gateway Gere a comunicação com o mundo exterior e outros sistemas CICS. Conceitos (5-11) Neste sistema, existe um conjunto de conceitos que explicam o funcionamento deste Monitor Transaccional em particular.

3 Transacção Não corresponde exactamente ao conceito de transacção nos Sistemas Gestores de Bases de Dados. É antes a designação dada a todo um processamento de informação que pode ser constituído por vários programas (application programs). Cada transacção tem um identificador e é invocada por um utilizador do sistema. Pode ser conversacional, em que existe mais do que um input do terminal ao longo do processamento, ou não-conversacional, em que assim que a transacção é invocada só termina quando todo o processamento se completa de uma forma sequencial. Pode-se encadear varias transacções não-conversacionais em que assim que cada uma termina, o controlo retorna ao utilizador. Este método é chamado pseudo-conversacional. LUW Logic Unit of Work É uma sequência de alterações aos dados relacionadas entre si. O trabalho realizado por uma LUW é independente do de outra LUW. O sistema CICS garante a atomicidade no trabalho realizado numa LUW. O seu inicio e fim pode ser definido pelo programador, caso contrario, o sistema assume toda a transacção como uma única LUW. Região (CICS Region) Designação dada ao ambiente onde correm as transacções e os programas. Mapa Funcionalidade que permite o relacionamento entre variáveis no código do programa e campos num dispositivo que mostra informação (por exemplo, um terminal), permitindo a visualização do valor de cada variável. O serviço que permite a implementação desta funcionalidade chama-se Basic Mapping Support e permite a utilização de um conjunto de macros para se definir mapas para uma aplicação em particular.

4 figura 2:Transacção com invocação de vários programas através dos comandos LINK e XCTL. O comando LINK invoca outro programa e bloqueia-se à espera do fim desse programa. O comando XCTL invoca outro programa mas não se bloqueia aguardando o retorno. figura 3: Transacção que utiliza o comando LINK correndo dois programas. Esta transacção consiste numa única LUW.

5 figura 4: Transacção idêntica à anterior, mas com três LUW's, definidas pelo programador através da utilização do comando SYNCPOINT. FNAME DFHMDF POS=(1,5),LENGTH=10, ATTRB=(UNPROT,BRT,FSET), INITIAL='XXXXXXXXXX',PICIN='X(10)', PICOUT='X(10)',COLOR=RED tabela 1: Definição em macros de dois campos de um mapa. figura 5: Exemplo de um terminal que mostra uma lista de informação. Foi gerado utilizando o serviço BMS. Utilizado numa instituição pública do estado do Texas. Programação em Ambiente CICS (12-16) Esta aplicação da empresa IBM, corre em varias plataformas:

6 Windows, Open Systems (Unix, Linux, AIX, HP-UX, etc..) e vários Sistemas Operativos proprietários da IBM. Um programador de aplicações que irão correr em sistema CICS, terá de seguir os seguintes passos: 1. Codificar o programa em qualquer linguagem suportada (Assembly, C, C++, COBOL, PL/I ). Os comandos CICS ficam embebidos no código e são identificados pelo prefixo exec cics 2. Traduzir o código gerado, em que os comandos são interpretados na linguagem utilizada. 3. Compilar, utilizando um compilador comum que já exista no sistema operativo. O programa é então linkado com as bibliotecas do sistema CICS. 4. Atribuir uma região onde o programa irá correr. 5. Associar o programa (identificado por um nome) a uma transacção, que também terá um identificador. Restrições à programação: 1. Nunca utilizar controlo de transacção da Base de Dados relacional que se está a aceder (COMMIT, ROLLBACK, etc...). Esta funcionalidade é da exclusiva responsabilidade do sistema e a razão de ser de um monitor transaccional. 2. Não fazer chamadas a fork(), exec() nem a qualquer função que lance processos utilizando a biblioteca nativa do sistema operativo. Seria mais dispendioso em termos de recursos. As funções de memória partilhada do sistema operativo e a função exit()estão também proibidas. Exemplo de código: 1 exec cics getmain set (buf) length (sizeof (struct buf_struct)); 2 3 buf->delta = delta; 4 buf->remote_account = remote_account; exec sql select amount from dosh_on_local_database 8 into :amount

7 9 where 10 account = :local_account; if (amount - delta < 0) { 13 report_to_user ("cant go overdrawn!"); 14 exec syncpoint rollback; 15 exec cics return; 16 } /* if */ exec sql update dosh_on_local_database 19 set amount = amount - :delta 20 where 21 account = :local_account and 22 amount = :amount; exec cics link program ('DBCT') sysid ('RMT') commarea (buf) length (sizeof (struct buf_struct)); 25 exec cics return; Comentários ao código: 1-6 Receber a estrutura buf e preenchê-la Fazer uma query na base de dados, através da invocação de um comando CICS Verificar se o levantamento é valido. Em caso afirmativo, invoca-se o SYNCPOINT ROLLBACK que cancelará toda a LUW (isto é, tudo desde o último SYNCPOINT caso tenha existido, ou desde o inicio da transacção) Fazer um update na base de dados. 24-Invocar o programa DBCT, através do comando LINK, é utilizado o parâmetro commarea com a estrutura buf como argumento para a passar como parâmetro a este programa. Também é enviado o tamanho da estrutura. A opção sysid ('RMT') indica que o programa a ser invocado está no sistema identificado como RMT. Isto tem a ver com o facto destes dois programas estarem em sistemas diferentes, tratando-se de DPL Distributed Program Link 25 Retorna o controlo para o programa invocador. Programa DBCT : 1 struct buf_struct *buf; 2 3 exec cics address commarea (buf); 4

8 5 exec sql select amount from dosh_on_remote_database 6 into :amount 7 where 8 account = :buf->remote_account; 9 10 if (amount + buf->delta) < 0) { 11 report_to_user ("can't go overdrawn!"); 12 exec cics abend nodump abcode ('ODRW'); 13 } /* if */ exec sql update dosh_on_remote_database 16 set amount = amount + :buf->delta 17 where 18 account = :buf->remote_account and 19 amount = :amount; exec cics return; Comentários ao código: 1-4 Inicializar e receber a estrutura buf através dos comando address utilizado para ler a memoria privada deste programa onde os parâmetros foram colocados pelo programa invocador. 5-9 Fazer uma query SQL à base de dados para saber a quantia disponível na conta Verificar se a conta, depois de um eventual levantamento, fica com saldo negativo. Em caso afirmativo, invocar o comando ABEND ( abnormal end ) que fará rollback à LUW em causa. O identificador (ODRW) do erro é passado ao programa que invocou e poderá tratar este retorno Fazer o update na base de dados (SQL) 21 Fazer return, retornando o controlo para o programa invocador. Bibliografia: Web Services, G Alonso et al, O livro da cadeira. Conceitos básicos sobre Monitores Transaccionais. Bernstein, TP Monitors, 1990 Artigo de 1990 em que se discutem diversos aspectos acerca de monitores transaccionais. CICS Application Programming Guide, IBM, 2004

9 Manual do programador. Bastante completo na descrição detalhada da API. A perspective on CICS DPL, Bob Yelavich ( Artigo do criador do CICS acerca de invocação distribuída de programas. Contem exemplos bastante elucidativos, porém, faltam as figuras. Recursos sobre o CICS no site da própria IBM. Mais recursos relacionados com o CICS. Empresa especializada. Vários recursos sobre o CICS. Contem o código utilizado nos exemplos.