Apresentação IDMS DC / DB COMPONENTS RESOURCES

Agenda
• IDMS/DC
• Journal
• Multitasking
• IDMS/DB
• DATABASE
• DMCL
• BUFFERS
• IDD

Agenda (cont)
• Segmentos
• Áreas
• Files
• Páginas
• DB-KEY
• DBTABLE
• DBNAME
• Dicionários
• Diagrama de Bachman
• Schema

Agenda (Cont)
• Subschema
• Performance Monitor (PMRM, PMAM, PMIM)
• Linguagens de programação
• SYSGEN
• OLQ
• Processamento em CV/Local Mode
• Comandos DCUF
• Comandos DCMT
• Deadlock, abend, abort

IDMS/DC
• CA IDMS/DC é um potente servidor de aplicações, voltado para
empresas de grande porte com a necessidade de manipular bilhões
de registros de forma altamente performática.
• O sistema CA IDMS/DC é o centro do ambiente operacional
multiusuário CA IDMS. CA IDMS/DC Controla:
• Gerenciamento de tasks
• Comunicações entre terminais
• Gerenciamento de scratch e queues
• Gerenciamento de Storage e programas

IDMS/DC
• Para criar um ambiente CA IDMS, instale o CA IDMS a partir de uma mídia
de instalação fornecida pela CA Broadcom. A mídia contém os programas e
arquivos necessários para instalar todos os softwares de apoio e o CA
IDMS, compatíveis com cada sistema operacional.
• O ambiente CA IDMS que você instala inclui os seguintes componentes:
• Bibliotecas de programas contendo os produtos CA IDMS/DB e CA IDMS/DC ou CA
IDMS UCF.
• Dicionário do sistema.
• Dicionário de aplicativos.
• Banco de dados de teste.
• Sistema CA IDMS/DC ou CA IDMS UCF. Este sistema é um sistema inicial que você
pode modificar para atender às necessidades do seu ambiente (SYSTEM 99).

IDMS/DC
• Para cada transação executada, a partir de terminais VTAM, TCP/IP ou
LU6.2, gerencia input/output de terminais, acesso aos dados nas
bases IDMS/DB, memória, journalização, LOGs, buffers, etc.
• Cada transação, ao ser iniciada, recebe uma área de memória com
demais recursos alocados.
• Pode ser chamado também de monitor de teleprocessamento, mas
desempenha funções muito além desta.

LOG do IDMS/DC
• O LOG do IDMS é onde são armazenadas as ocorrências de signed on,
signed off, aborts, deadlock, abends, displays, etc.
• O LOG é uma área chamada de DDLDCLOG, ela é swap around, ou seja,
quando enche, volta a escrever no início, e é single trheaded.
• Qualquer ocorrência no ambiente é armazenada lá.
• Eu costumo dizer que você tem dois melhores amigos; o LOG e os manuais.
Use e abuse dessas duas ferramentas e explore o quanto puder.
• O LOG pode ser visualizado de 3 formas:
• OLP
• LOGD
• Print LOG batch

Journal
• Toda atividade do banco de dados é registrada em um arquivo de
journal em disco. CA IDMS/DB grava as seguintes informações no
journal:
• Entradas de registro de journal que contêm a imagem de registros de banco
de dados
• Checkpoints que descrevem o status das transações que acessam o banco de
dados
• Devem ser definidos, no mínimo, 3 arquivos de journal. Sempre que
um arquivo estiver cheio, o IDMS/DC efetua um swit automático para
o próximo journal livre e efetua descarga e offload do journal cheio
para o archive, que é um acumulado do dia.

Writing Journal Blocks
• CA IDMS/DB acumula registros de journal no buffer de journal. Ele
descarrega o buffer de journal em um arquivo de journal quando
ocorre uma das seguintes condições:
• O buffer está cheio.
• Uma página contendo uma ocorrência de registro atualizado, cuja imagem
anterior está no buffer do journal, deve ser gravada de volta no banco de
dados.
• Uma transação do banco de dados foi confirmada (COMMIT) ou restaurada
(backed out). Uma transação confirma (COMMIT) ou retrocede (backed out)
como resultado de uma solicitação explícita, como FINISH ou ROLLBACK ou
porque a transação é abortada.

Journal Record Entries
• Registrar alterações em registros:
• CA IDMS/DB usa entradas de registro de journals para registrar alterações nos
registros em um banco de dados. Uma entrada de registro de journal é uma
imagem de um registro de banco de dados. Conforme um registro de banco
de dados é adicionado, excluído ou modificado, o CA IDMS/DB grava uma
imagem anterior (before image) que contém a imagem do registro antes da
atualização e uma imagem posterior (after image) que contém a imagem do
registro após a atualização.

Journal - Checkpoints
• Checkpoints descrevem o status das transações de banco de dados. CA
IDMS/DB escreve esses checkpoints no arquivo de journal:
• Checkpoint:
• BGIN
• Escrito no arquivo de journal para marcar o início (BEGIN) do trabalho local realizado
por cada transação individual de uma transação distribuída. Este checkpoint é
gravado quando uma transação do banco de dados é iniciada se JOURNAL RETRIEVAL
for especificado na SYSGEN, ou quando a primeira atualização ocorrer.
• ENDJ
• Escrito no arquivo de journal durante o COMMIT para marcar a conclusão bem
sucedida de cada transação individual de uma transação distribuída.

• Checkpoint:
• COMT
• Escrito no arquivo de journal durante o COMMIT para marcar a conclusão
bem sucedida de cada transação individual de uma transação distribuída.
COMT é similar a ENDJ, exceto que permite que o trabalho feito após o
commit seja registrado no arquivo de journal usando o mesmo Local identifier
(LID). Um LID é um valor de 4 bytes incrementado em série que identifica
exclusivamente o trabalho realizado por cada transação individual de
transação local.
• ABRT
• Escrito no arquivo de journal , durante o BACKOUT para marcar a conclusão
anormal de cada transação individual de uma transação distribuída.

• Checkpoint:
• BFOR
• Escrito no arquivo de journal, cada vez que um registro é atualizado, e carrega
a imagem daquele registro antes (BEFORE) que as alterações sejam efetuadas.
• AFTR
• Escrito no arquivo de journal , cada vez que um registro é atualizado, e
carrega a imagem daquele registro depois (AFTER) que as alterações foram
efetuadas.

• Checkpoint:
• CKPT
• Escrito no arquivo de journal, para marcar a conclusão simultânea, com êxito,
de várias transações individuais de uma transação local. Este checkpoint é
usado para coordenar a confirmação de uma transação local envolvendo
várias transações
• Obs: ENDJ, COMT, e ABRT checkpoints são escritos no arquivo de
journal somente para transações que escreveram também um BGIN.

O que é Multitasking
• Despachando em um sistema Unitasking
• Despachando em um sistema Multitasking
• Subtasks
• Modes
• CA IDMS components in MPMODE ANY

Multitasking
• É a possibilidade de execução de várias tasks simultâneas em um
único IDMS/DC, é análogo a ter vários IDMS/DC executando em paralelo.
• Multitask é autoajustável, adicionais subtasks só serão usadas se
necessário. Melhora o desempenho das aplicações na medida em que
aproveita os processadores disponíveis.
• Multitask aumenta o throughput (rendimento) e reduz o tempo de
resposta do ambiente como um todo.
• É facilmente implementado, bastando adicionar ao PARM do JCL de
startup, os parâmetros MT=Y e SUBTASKS=10. No exemplo abaixo estamos
estipulando 10 subtasks.
• //R150DC99 EXEC PGM=IDMSDC,REGION=0M,TIME=1440,
• // PARM='DMCL=DMCL150,MT=Y,SUBTASKS=10'

Multitasking
R10
RHDCCSA
+518
TCB TCB TCB
TCB
MAINTASK
+0 +0 +0
SUBT0001 SUBT0002 SUBT0003

Multitasking - Modes
• A opção de multitasking do IDMS é implementada categorizando o trabalho do IDMS em diferentes
estados/MP Modes: DB, DC, LOADER, DRIVER, USER e ANY.
• ANY - Atribuído a todo código de usuário e código de sistema que não requer serialização. ANY é para
programas que não atualizarão nenhuma área de memória associada a outro programa. Portanto, é
seguro para um programa atribuído a MPMODE ANY executar simultaneamente com outros
programas.
• DB - Atribuído a módulos que executam atividades de banco de dados, como processamento de
registros, bloqueio de registros e controle de simultaneidade.
• DC - Atribuído a todos os módulos não-DB, incluindo a maioria dos programas escritos pelo usuário em
execução sem storage protect. Diálogos e programas COBOL podem ser atribuídos MPMODE=ANY.
• DRIVER - Assigned to all IDMS line drivers (for example, VTAM and UCF).
• LOADER - Atribuído a rotinas de carregamento de programas; programas de usuário não podem ser
atribuídos à este modo.
• USER - Atribuído a programas de usuário em execução com storage protect e a programas VS COBOL
não protegidos.

Multitasking
• Componentes do sistema do CA IDMS executando em MPMODE=ANY
• Dispatcher
• Task-local functions
• Storage manager
• Scratch manager
• Motor de banco de dados
• Motor de segurança

Monitoração
• DCMT commands
• DCMT DISPLAY SUBTASK
• DCMT DISPLAY MPMODE
• DCMT D SUBT EFF
• CA IDMS Performance Monitor

Monitoração
• Interativa (Em tempo real)
• Performance Monitor (PMRM)
• Comandos DCMT
• OPER

Monitoração
• Pós processamento
• Relatórios do Performance
• Application Monitor - PMAM
• Interval Monitor - PMIM
• SREPORTS
• Ferramentas de monitoração em tempo real podem, também, ser utilizadas
para monitorações pós o processamento
• PMRM
• PMIM

IDMS/DB
• CA IDMS ™ é um sistema de gerenciamento de banco de dados econômico, confiável, de
alto desempenho e seguro para o ambiente IBM Z. Um poderoso mecanismo de banco
de dados que fornece acesso relacional e de REDE, explorando as tecnologias de
hardware e software mais recentes, incluindo o IBM z Systems Integrated Information
Processor (zIIP).
• O sistema de gerenciamento de banco de dados possibilita o acesso aos dados de seu
banco de dados. Ele garante que os dados sejam consistentes e coordena o acesso aos
dados usando locks. O DBMS fornece integridade de dados por meio de serviços de
recuperação automática e tem várias opções de ajuste, como clustering e compactação
de dados.
• Fundamentalmente é um banco de dados em REDE, interligando pais e filhos por
ponteiros físicos. A comunicação ocorre do pai para o filho e do filho para o pai. O
ponteiramento físico garante alta performance do banco de dados.

IDMS/DB - Preparação do ambiente
• Depois de ter um sistema DC/UCF, você pode preparar seu ambiente de
produção. O processo é como se segue:
• Projete o banco de dados
• Defina o banco de dados
• Carregue o banco de dados
• Desenvolver e testar aplicativos
• Estabeleça o ambiente de produção
• Em cada etapa, você deve:
• Estabeleça e aplique convenções de nomenclatura para entidades como squemas,
áreas de banco de dados, registros ou tabelas e módulos de aplicativo.Um conjunto
de convenções de nomenclatura padronizadas que atendem às suas necessidades
corporativas economizará muito tempo e confusão e ajudará a garantir um ambiente
CA IDMS eficiente e eficaz.
• Implemente medidas de segurança para proteger entidades como banco de dados,
dicionário de dados e sistema DC/UCF contra acesso não autorizado.

IDMS/DB - Design the Database
• Projetar um banco de dados envolve as seguintes atividades:
• Desenvolva um design para o banco de dado
• Decida sobre uma implementação para esse design lógico
• O design do banco de dados é o processo de determinar as entidades de dados fundamentais necessárias
para dar suporte aos negócios da corporação.
• Durante o estágio inicial de design, você coleta informações sobre as funções de negócios executadas em
sua empresa. Por meio da análise dessas funções, você identifica os tipos de dados que são manipulados
pelas funções e determina os relacionamentos entre os tipos de dados. Usando técnicas de modelagem de
dados, você cria um diagrama que serve como um modelo lógico do recurso de dados corporativos.
• Depois que o design inicial estiver concluído, você aprimora esse design para atender aos requisitos
específicos de desempenho e processamento do aplicativo.
• Durante este estágio, você determina os índices e outras chaves de acesso usadas para atender aos objetivos
de desempenho necessários e estruturas de design para otimizar os recursos de armazenamento.

IDMS/DB - Define the Database
• Neste ponto, você deve decidir sobre a linguagem de definição lógica e traduzir o
design em estruturas CA IDMS apropriadas para essa implementação. Se você
escolher SQL, você deve:
• Defina o banco de dados físico
• Formate os arquivos do sistema operacional (files)
• Defina o banco de dados lógico
• Se você escolher não SQL, poderá definir o banco de dados lógico antes ou depois
de definir o banco de dados físico e formatar os arquivos do sistema operacional.

IDMS/DB - Load the Database and Test
• Carregue a base de Dados:
• Depois que a definição do banco de dados físico e lógico for concluída, você carrega os dados
no banco de dados. Esses dados podem vir de outro banco de dados ou de arquivos
sequenciais.
• Algumas tabelas serão carregadas pela própria aplicação.
• Desenvolver e testar aplicativos:
• Depois de carregar os dados no banco de dados, você pode continuar a desenvolver e testar
os aplicativos.

IDMS/DB - Physical Database Definition
• Além de definir os componentes lógicos do banco de dados, você define as
características físicas dos dados e o ambiente no qual eles são acessados. Isso é
chamado de definição física de banco de dados.
• A definição física do banco de dados físico inclui o seguinte:
• Segmentos, áreas e files que conterão os dados.
• Buffers que são usados na recuperação e armazenamento de dados.
• Arquivos de journal usados para recuperação.
• A definição física do banco de dados é armazenada no dicionário do sistema, pois
representa todos os dados acessíveis por meio do ambiente de execução.

IDMS/DB - Logical Database Definition
• A definição lógica do banco de dados identifica a visão dos dados do usuário.
• A definição lógicado banco de dados inclui:
• Definição de registros, tabelas e views.
• Definições de relacionamentos entre essas entidades.
• Especificação de regras de integridade.
• Especificação de índices e outras chaves de acesso.
• As definições lógicas do banco de dados residem no dicionário do aplicativo.

IDMS/DB - Physical Database Definition
• Um banco de dados físico é uma coleção de dados que reside em arquivos do
sistema operacional. CA IDMS/DB usa informações fornecidas em tempo de
execução para determinar como mapear a representação lógica do banco de
dados para uma das muitas implementações físicas do banco de dados.
• A definição de um banco de dados físico é representada como um segmento.
Um segmento define as áreas (ou seja, arquivos lógicos) e arquivos físicos que
contêm os dados no banco de dados. Para que o CA IDMS/DB acesse o segmento
em tempo de execução, o segmento deve ser adicionado à definição de uma
DMCL.

IDMS/DB - DMCL
• DMCL é uma coleção de definições de segmentos que podem ser acessadas em um único CA IDMS/DB.
Uma DMCL existe como um módulo de carga em uma biblioteca de carga e é usada em tempo de
execução para determinar onde os dados exigidos por um aplicativo estão armazenados fisicamente.
• Uma DMCL também executa as seguintes tarefas:
• Atribui o espaço de buffer necessário para processar os dados.
• Descreve arquivos e buffer para a atividade de journal do banco de dados.
• Identifica uma tabela de nomes de banco de dados, que o CA IDMS/DB usa, em tempo de execução, para mapear
uma definição de banco de dados lógico para uma definição de banco de dados físico.
• Especifica atributos relacionados ao compartilhamento de dados.
• Identifica as áreas do banco de dados a serem compartilhadas entre os membros de um grupo de data sharing.
• Na maioria dos casos, você precisará de apenas uma DMCL por ambiente. Por exemplo, se você
mantiver configurações de teste e produção separadas, cada uma terá sua própria DMCL. Todos os
aplicativos executados em Central Version usam uma única DMCL conforme especificado nos
parâmetros de inicialização do sistema. Os aplicativos executados em local mode também podem usar
esta DMCL.
• Em local mode, você pode querer usar uma DMCL feita sob medida para aplicativos específicos, como
efetuar Load de um Database. Você pode especificar o nome da DMCL para uso em local mode no
arquivo de parâmetro SYSIDMS. Se você não especificar uma DMCL explicitamente, CA IDMS/DB
assume queao DMCL é definida como default para a CV.

IDMS/DB - Segments
• Representa um banco de dados físico
• Um segmento representa um banco de dados físico geralmente definido por um único
esquema. Ele descreve a coleção de áreas e arquivos contendo os dados do banco de dados.
Uma definição lógica (esquema) pode ser associada a uma ou mais definições físicas
(segmentos). Cada um desses segmentos contém áreas e files.

IDMS/DB - Segments
• A seguir está uma ilustração de um banco de dados físico:

IDMS/DB - Áreas
• As áreas definem o intervalo de páginas do banco de dados:
• Uma área é um arquivo lógico dividido em páginas de banco de dados. Uma página de banco
de dados representa um bloco de arquivos lógicos.
• Páginas de banco de dados armazenadas fisicamente em arquivos:
• Você atribui páginas de uma área a um ou mais arquivos de disco físico que existem em
volumes de acesso direto. Em tempo de execução, CA IDMS/DB mapeia uma página em uma
área para um ou mais blocos em um arquivo; a maneira como CA IDMS/DB mapeia uma
página de banco de dados para um arquivo físico depende do método de acesso do arquivo.

IDMS/DB - Defining Buffers in a DMCL
• Um buffer de banco de dados é o espaço alocado na memória para conter as páginas do banco de
dados enquanto o IDMS/DB acessa as informações nessas páginas. Um buffer é dividido em páginas. Se
as informações na página forem atualizadas, IDMS/DB grava a página alterada de volta no banco de
dados quando essa página de buffer é necessária ou quando a transação termina.
• Um buffer de banco de dados deve ser definido para uma DMCL antes de você poder adicionar
segmentos à DMCL. Cada arquivo contido nos segmentos adicionados à DMCL deve estar associado a
um buffer.
• Para definir um buffer na DMCL utilize o comando abaixo:
CREATE BUFFER IDMSDMCL.BUF1_DB_6000
PAGE SIZE 6000 CHARACTERS
LOCAL MODE BUFFER PAGES 50
OPSYS STORAGE
CENTRAL VERSION MODE BUFFER
INITIAL PAGES 1000
MAXIMUM PAGES 2000
OPSYS STORAGE ;

IDMS/DB - Defining Segments
• O exemplo a seguir cria um segmento para um banco de dados não SQL. As instruções no
exemplo definem o segmento, seus arquivos e áreas associados. As características do
segmento são:
• Segmento EMPSEG - Por padrão, CA IDMS/DB atribui estes valores.
• Page Group: 0
• Máximo de registros por página: 255
• Arquivo EMPDEMO1 - EMPDEMO1 é um arquivo não-VSAM com o file name
CORP.SYSPUB.EMPFILE1. Ele será acessado usando um ddname EMPFILE1, a menos que
seja substituído por um parâmetro da DMCL.
• Área EMPAREA - A área EMPAREA possui os seguintes atributos:
• 2.000 páginas, começando na página 80001. Essas páginas serão usadas para armazenar
ocorrências de registro atribuídas à área. A definição prevê expansão futura da área porque
especifica uma cláusula MAXIMUM SPACE.
• Page size de 6.000 bytes.
• Uma associação com o arquivo EMPDEMO1 que, por padrão, contém toda a área, começando no
bloco 1 do arquivo.

IDMS/DB - Defining Segments
create segment empseg
for nonsql
Page group 0
maximum records per page 255;
create file empseg.empdemo1
assign to empfile1
dsname 'corp.syspub.empfile1'
disp shr
nonvsam;
create physical area empseg.emp-area
page group 0
primary space 2000 pages from page 80001
maximum space 2500 pages
page size 6000 characters
within file empdemo1
from 1 for all blocks;

IDMS/DB - Adding Segments to the DMCL
• Segmentos exigidos para uma Central Version:
• A DMCL usado em central version deve conter descrições físicas de todos os segmentos a serem
acessados pela CV. Os segmentos incluem aqueles que definem:
•
• . O dicionário do sistema.
• . O catálogo do usuário.
• . Áreas de sistema adicionais necessárias para operações da CV:
• . DDLDCLOG
• . DDLDCRUN
• . DDLDCSCR
• . SYSMSG.DDLDCMSG
• . Um ou mais dicionários de aplicativos.
• . Um ou mais bancos de dados de usuário.
•
• O catálogo do usuário pode não ser necessário, dependendo de sua implementação de
segurança.

IDMS/DB - Adding Segments and files to DMCL
alter dmcl idmsdmcl
include segment empseg
on startup set status to retrieval
on warmtart maintain current status
data sharing no
default shared cache null
include file empseg.empdemo1
buffer BUF1_DB_6000
shared cache default
memory cache no
include area empseg.emp-area
page size is 6000 characteres
on startup set status to offline
on warmstart maintain current status
data sharing no
memory cache no
Page reserve 250 characteres ;

IDMS/DB - Procedure for Defining a DMCL
Action Statement
Create the DMCL CREATE DMCL
Create one or more database buffers CREATE BUFFER
Create 1 journal buffer CREATE JOURNAL BUFFER
Create 2 or more disk journal files CREATE DISK JOURNAL
Create 1 or more archive journal files CREATE ARCHIVE JOURNAL
Add all segments to be used under the central version
or in local mode
ALTER DMCL with the ADD SEGMENT clause
Optionally, override file or area definitions contained
in segments associated with the DMCL
ALTER DMCL with the ADD FILE or ADD AREA clauses
Associate a database name table with the DMCL ALTER DMCL with the DBTABLE clause

IDMS/DB - Defining a DMCL
create dmcl proddmcl dbtable proddbs;
create buffer big_buffer
page size 4096
local mode buffer pages 100
opsys storage
central version mode buffer
initial pages 500
maximum pages 1500
opsys storage;
create journal buffer jrnlbuff
page size 4096
buffer pages 3;
create disk journal diskjnl1
file size 1000
assign to sysjnl1;
file size 1000
assign to sysjnl2;
file size 1000
assign to sysjnl3;
create archive journal archjrnl
block size 16000
assign to sysajnl1;
alter dmcl proddmcl
default buffer big_buffer
add segment system
add segment defdict
add segment empdict
...
add segment empseg;

IDMS/DB - Gerando a DMCL
• Gere o módulo de carga da DMCL emitindo uma instrução GENERATE.
• generate dmcl idmsdmcl ;
• Link-edit o módulo objeto resultante para uma biblioteca de carga usando
o linkage-editor do seu sistema operacional. O nome com o qual você
vincula a DMCL é o nome pelo qual a DMCL é conhecido em tempo de
execução. Portanto, você pode definir diferentes DMCLs, por exemplo, uma
para a CV, uma para o batch e outra para as manutenções de banco.
• Na CV, especifique o nome DMCL nos parâmetros de inicialização do
sistema DC/UCF.
• Se o nome da DMCL a ser usado em local mode não for o mesmo,
identifique a DMCL de LM no arquivo de parâmetro SYSIDMS.

IDMS/DB - Database Keys (DB-KEY)
• Identify Each Record Occurrence
• Cada ocorrência de registro em um banco de dados CA IDMS é identificada exclusivamente
por uma chave de banco de dados(db-key), que indica a localização física da ocorrência no
banco de dados. Uma db-key é atribuída quando uma ocorrência de registro é armazenada
no banco de dados. A db-key nunca muda enquanto o registro permanecer no banco de
dados (isto é, até que o registro seja apagado ou até que o banco de dados seja
reorganizado).
• Used as Pointers
Database keys são usadas como ponteiros relacionados a ocorências de registros ou registros de
índice. Assim, as chaves do banco de dados são encontradas nos prefixos mantidos pelo sistema
que precedem a parte dos dados da ocorrência do registro. Por exemplo, o prefixo de uma
ocorrência de registro pode conter as db-keys dos registros seguinte, anterior e do owner em um
chained set do qual essa ocorrência é membro.
A db-key é um númeroo binário de 4-byte (32 bit) . The Database Management System (DBMS) cria
a db-key para uma ocorrência de registro, concatenando os seguintes números:
• Page number -- A página onde o registro é armazenado.
• Line number -- A posição do line index da ocorrência de registro na página em relação aos outros line index,
onde o line index para o registro SR1 é 0.

IDMS/DB - Database Keys (DB-KEY)
• Db-key Format
• O formato da db-key é variável. O número de bits reservados na
db-key para o número da página e o line number,
respectivamente, pode variar de um banco de dados físico para
outro, desde que o número total de bits usados seja 32. Você
identifica o formato da db-key como sendo usado especificando o
número máximo de ocorrências de registro a serem armazenadas
em uma página do banco de dados na instrução CREATE SEGMENT.
• Exemplo: 999:30

IDMS/DB - DBTABLE
• Mapeia a definição lógica para a física:
• Uma tabela de nomes de banco de dados (DBTABLE) é uma entidade associada a uma DMCL,
e é usada para mapear a definição de banco de dados lógico para um ou mais segmentos na
DMCL.
• Conteúdo de uma DBTABLE:
• A definição de uma DBTABLE inclui um ou mais DBNAMES. Cada DBNAME identifica os
segmentos a serem acessados como parte do banco de dados lógico. Uma DBTABLE também
pode incluir uma ou mais declarações de grupo de banco de dados.
• Nomes de grupo para roteamento dinâmico:
• Em um ambiente parallel sysplex, uma DBTABLE também pode definir grupos de banco de
dados (DBGROUPs) que representam coleções de Central Versions para as quais as
solicitações podem ser roteadas dinamicamente. Uma solicitação de banco de dados pode
ser atendida em qualquer Central Version cuja DBTABLE inclua o grupo de banco de dados
para o qual a solicitação é direcionada.
• Tabela de nomes de banco de dados usada em tempo de execução:
• Uma DBTABLE é usada pelo CA IDMS/DB em tempo de execução para acessar as definições
físicas do banco de dados. Ela deve existir como um módulo de carga em uma biblioteca de
carga.

IDMS/DB - Procedure for Defining a DBTABLE
Action Statement
Create the database name table, adding DBTABLE
mappings to define a default dictionary and for non-
SQL applications binding without a DBNAME
CREATE DBTABLE
Create the database names, adding the segments and
subschema mappings required by your applications
CREATE DBNAME
Generate the database name table GENERATE DBTABLE
Associate the database name table with a DMCL ALTER DMCL
Punch the database name table load module and link-
edit it to a load library
PUNCH DBTABLE LOAD MODULE

IDMS/DB - Defining a DBTABLE
create dbtable alldbs
subschema idmsnwk? maps to idmsnwk? dbname defdict
subschema ???????? maps to ???????? dbname defdb;
create dbname system
segment catsys
segment system
segment sysmsg;
create dbname defdict
segment defdict
segment defcat ◄-- for SQL users
segment sysmsg;
create dbname defdb
segment user-segment1
segment user-segment2
.

IDMS/DB - DBNAME
• Exemplo de DBNAME:
create dbname alldbs.abc
add segment testdict
add segment testcat
add segment sysmsg
add segment empseg;
• Exemplo de mapeamento de subschema:
create dbname alldbs.empdb
subschema empt???? maps to empp????
IDMS/DB -

IDMS/DB DBNAME – Identificando segmentos
• Ao dar bind em uma RUN UNIT, o sistema deve determinar qual segmento
(ou segmentos) contém os dados a serem acessados. Embora o subsquema
identifique as áreas, podem haver várias áreas com o mesmo nome na DMCL.
Para determinar qual área acessar, o sistema deve qualificar o nome da área com
o nome de um segmento.
• Para determinar os segmentos a serem acessados, o nome de um segmento ou
banco de dados deve ser fornecido em tempo de execução. Esse nome pode ser
especificado de uma das seguintes maneiras:
• Pelo aplicativo, usando o parâmetro DBNAME na instrução BIND RUNUNIT.
• A partir do atributo de sessão DBNAME. Os atributos da sessão são estabelecidos através de
perfis de usuário ou sistema, comandos DCUF SET em DC/UCF ou parâmetros SYSIDMS no
batch.
• Do valor DBNAME em um arquivo SYSCTL ou um módulo IDMSOPTI vinculado ao aplicativo.
• Da DBTABLE por meio do uso de regras de mapeamento.
•

IDMS/DB - Dicionários
• O que é um dicionário: Para oferecer suporte ao ambiente em tempo de execução, certas informações
são necessárias para definir e controlar esse ambiente. Essas informações são armazenadas em
dicionários.
• Um dicionário é um banco de dados especial definido pelo CA IDMS que contém definições de:
• Outros bancos de dados
• Sistemas CA IDMS/DC ou CA IDMS UCF
• Aplicativos escritos pelo usuário
• Os dois tipos de dicionários usados no ambiente CA IDMS são os dicionários do sistema e os dicionários
do aplicativo.
• Dicionário do Sistema:
• O dicionário do sistema contém definições do sistema DC/UCF e definições do banco de dados
físico. Pode haver apenas um dicionário do sistema em um ambiente de tempo de execução.
• Dicionário da Aplicação:
• Um dicionário de aplicativo contém definições de aplicativo e definições de banco de dados lógico.
Isso inclui registros, relacionamentos, áreas, esquemas, subesquemas, mapas e diálogos.
• Pode haver zero, um ou mais dicionários de aplicativos em um ambiente.

Diagrama de Bachman
• Na década de 1960 e 70, Charles Bachman (falecido em 2017, aos 92
anos) e A.P.G. Brown trabalhavam a abordagem de Peter
Chen. Bachman desenvolveu um tipo de diagrama de estrutura de
dados, batizado de diagrama de Bachman. Brown publicou trabalhos
sobre modelagens de sistemas do mundo real. James Martin
acrescentou refinamentos aos DERs. Os trabalhos de Chen, Bachman,
Brown, Martin e outros também contribuíram para o
desenvolvimento da Linguagem de modelagem unificada (UML,
Unified Modeling Language, em inglês), amplamente utilizada em
design de software.
• DER – Diagrama de entidade e relacionamento.

IDMS/DB - IDMSDDDL
• A Linguagem de Definição de Dicionários de Dados (DDDL) é a linguagem fonte usada
para manter os componentes de recursos de dados no dicionário. A entrada para o
compilador DDDL consiste em comandos fonte; o compilador processa a entrada e
preenche o dicionário de dados. Uma vez adicionados ao dicionário, as definições de
recursos de dados podem ser modificadas, substituídas, excluídas, vistas ou dado punch
usando a syntax DDDL.
• Pra que serve:
• Utilizada para inclusão de registros e elementos que serão utilizados no comando
SHARE do registro no schema.
• Formas de dar manutenção nos dicionários:
• Batch através do utilitário IDMSDDDL.
• Online através da task IDD.
• Online através da task IDDM (em forma de Menu).

IDMS/DB - IDMSDDDL
• Exemplo de inclusão de um elemento:
add element name is customer-number version is 1
element synonym is customer_number for group synonym customer_group
element synonym is custnum for group synonym cust
grupelement synonym is custno for group synonym custgp
picture is 9(6).

IDMS/DB - IDMSDDDL
• Exemplo de inclusão de um registro:
add record name is customer-record version is 1.
05 cust-nr-numeric ver 1 pic 9(10).
05 cust-ssn ver 2.10 cust-ssn-3 ver 1 pic x(03).
10 cust-ssn-2 ver 1 pic x(02).
10 cust-ssn-4 ver 1 pic x(04).
05 cust-address ver 2.
10 cust-street ver 1 pic x(20).
10 cust-addr2 ver 2.
15 cust-city ver 2 pic x(13).
15 cust-state ver 1 pic x(02).
15 cust-zip-code ver 2.20 filler pic x(04).

IDMS/DB - Logical Database Definition
• A definição lógica do banco de dados identifica a visão dos dados do usuário.
• A definição lógicado banco de dados inclui:
• Definição de registros, tabelas e views.
• Definições de relacionamentos entre essas entidades.
• Especificação de regras de integridade.
• Especificação de índices e outras chaves de acesso.
• As definições lógicas do banco de dados residem no dicionário do aplicativo e são
chamadas de schemas e subschemas.

IDMS/DB - Schema Statement
• As definições no SCHEMA identificam o esquema como um todo. Além
disso, as definições do SCHEMA podem:
• Adicionar, modificar, excluir, exibir ou dar punch em um esquema.
• Estabelecer segurança para o esquema.
• Autorizar os usuários a emitir comandos específicos para o esquema.
• O exemplo a seguir fornece a declaração mínima do SCHEMA, necessária
para se estabelecer um banco de dados funcional:
•
• add schema name is sampschm.

IDMS/DB - Area Statement
• As definições da AREA identificam uma área lógica do banco de
dados. Dependendo do verbo e das opções codificadas, as instruções
AREA também podem:
• Adicionar, modificar, excluir, exibir ou dar punch em uma área.
• Determine quais (se houver) Database procedure serão executadas quando a
área for acessada em tempo de execução.
• O exemplo a seguir fornece a definição mínima de ÁREA, exigida para
que a área seja um componente válido do esquema:
• add area name is emp-demo-region.
• O compilador de esquema aplica as definições da AREA ao esquema
atual.

IDMS/DB - Record Statement
• As instruções RECORD identificam um tipo de registro de banco de dados. Dependendo do verbo, das opções e das
subinstruções codificadas, as instruções RECORD também podem:
• Adicionar, modificar, excluir, exibir ou dar punch em um registro.
• Atribuir o registro a uma área de banco de dados.
• Determinar quais (se houver) Database procedures serão executados quando as ocorrências do registro forem
acessadas em tempo de execução.
• Criar uma estrutura de registro, ou seja, uma descrição de dicionário do registro, incluindo seus sinônimos,
elementos e sinônimos de elementos; associar o registro a uma estrutura existente.
• Record Statment:
• add record name is skill
• share structure of record skill
• of schema othrschm
• location mode is calc using skill-code
• duplicates are not allowed
• within area org-demo-region
• minimum root length is control length
• minimum fragment length is record length
• call idmscomp before store
• call idmscomp before modify
• call idmsdcom after get.
• O compilador de esquema aplica instruções RECORD ao esquema atual.

IDMS/DB - Element Substatement
• O subcomando de elemento associa um elemento ao registro e, se o elemento
ainda não existir, adiciona a descrição do elemento ao dicionário. As descrições
dos elementos do esquema não podem ser modificadas ou excluídas. Para alterar
as descrições dos elementos, modifique a descrição do registro e especifique
novamente todos os elementos do registro.
• O exemplo a seguir fornece a definição mínima de um Elemento.
• 02 claim-date.
• 03 claim-year picture 99.
• 03 claim-month picture 99.
• 03 claim-day picture 99.
• Um registro e seus elementos são definidos no IDD, usamos o comando share
para relacionar o registro com o schema.

IDMS/DB - SET Statement
• As instruções SET identificam e descrevem um SET de ligação entre dois
registros. Dependendo do verbo, as instruções SET podem adicionar,
modificar, excluir, exibir ou dar punch em um SET.
• O compilador de esquema aplica as definições do SET ao esquema atual.
• O exemplo a seguir fornece a definição SET onde os ponteiros são apontados manualmente.
• add set name is job-position
• order is next
• mode is chain linked to prior
• owner is job
• next dbkey position is 1
• prior dbkey position is 2
• member is emposition
• next dbkey position is 1
• prior dbkey position is 2
• linked to owner
• owner dbkey position is 3
• optional manual.

IDMS/DB - Index Statement
• Um índice é uma forma de ordenar uma tabela logicamente para
acelerar a recuperação de dados.
• Por exemplo, um índice pode ser definido para ordenar a tabela
EMPLOYEE pelo sobrenome do funcionário. Outro índice poderia ser
estabelecido para ordenar a mesma tabela por número de CPF.
• Um índice é estabelecido em uma coluna ou combinação de colunas:
• Para melhorar a eficiência do processamento.
• Para evitar linhas duplicadas (quando um índice é especificado como único).

IDMS/DB - VALIDATE Statement for Schema
• Comando VALIDATE:
• Quando o compilador de esquema valida o esquema, ele executa uma das seguintes
ações:
• Se não encontrar erros, o compilador definirá o status do esquema como VALID. VALID indica que
o esquema pode ser usado pelo IDMS/DB.
• Se encontrar erros, o compilador define o status do esquema como IN ERROR e emite mensagens
indicando a natureza exata de cada erro. O DBA usa essas mensagens para determinar quais
mudanças devem ser feitas para que o esquema seja válido. Contanto que o status seja IN ERROR,
o IDMS/DB não poderão usar o esquema.
• Exemplo:
• modify schema name is culschem version 6
• revision number is '6.5'
• text is 'accommodate new billing procedures'
Validate.
• Obs: Pode-se utilizar também o comando Regenerate affected subschemas.

IDMS/DB - Subschema Statements
• As instruções SUBSCHEMA identificam o subesquema como um todo.
• As instruções SUBSCHEMA podem:
• Adicionar, modificar, excluir, exibir ou dar punch em um subesquema.
• Estabelecer segurança para o subesquema.
• Autorizar os usuários a emitir comandos específicos para o subesquema.

IDMS/DB - Subschema Statements
• Exemplo de um subschema:
add subschema name is dehss01 of schema empschm version 100.
add area name is emp-demo-region
shared update is allowed
default usage is shared retrieval.
add record name is employee.
add record name is Departamento.
add set name is dept-employee.
add index dept-cpf-ndx.
generate.

Using the Schema and Subschema Compilers
• Compiladores de esquema, subesquema e DDDL.
• Os compiladores batch e online, do schema, subschema, and data
dictionary definition language (DDDL) são usados para definir e manter a
definição lógica de bancos de dados:
• Compilador de schema - usado para criar uma definição de banco de dados não SQL
lógica completa.
• Compilador de subschema - usado para criar uma visão de subconjunto da definição
de banco de dados lógico para uso em programas de aplicativos.
• Compilador DDDL - usado para criar definições de registro e elemento no dicionário.
• Utilities:
• Você usa utilitários para realizar operações de manutenção no banco de dados. A
maioria dos utilitários é executada pelo command facility; no entanto, alguns são
programas independentes, desenvolvidos mos próprios sites.

Linguagens de Programação
• DC COBOL
• OBTAIN CALC ACCOUNT
• MODIFY ACCOUNT
• STORE HISTORY
• OBTAIN KEEP OWNER WITHIN BRANCH-ACCOUNT
• MODIFY BRANCH
• OBTAIN KEEP TELLER WITHIN BRANCH-TELLER USING TELLER-NUMBER
• MODIFY TELLER

SYSGEN
• System generation é o processo de definição e manutenção do
Sistema que controla execuções em central version e operações
online no ambiente CA IDMS.
• Todas as linhas, VTAM, UCF, MQ e TCP/IP, com seus respectivos
terminais devem ser definidas. Programas COBOL e ASSEMBLER
também devem ser definidos para que possam ser executados.
• Obs: Diálogos não precisam ser cadastrados, são carregados
automaticamente do dicionário.

SYSGEN - Definição do SYSTEM
• SYSTEM 120
• DEADLOCK DETECTION INTERVAL IS 1
• EXTERNAL WAIT IS 60
• INACTIVE INTERVAL IS 180
• INTERNAL WAIT IS 30
• JOURNAL FRAGMENT INTERVAL IS 0
• JOURNAL TRANSACTION LEVEL IS 5
• NOJOURNAL RETRIEVAL
• STORAGE LIMIT FOR ONLINE TASKS IS 5000
• STORAGE LIMIT FOR EXTERNAL TASKS IS 5000
• LOCK LIMIT FOR ONLINE TASKS IS 500000
• LOCK LIMIT FOR EXTERNAL TASKS IS 500000
• CALL LIMIT FOR ONLINE TASKS IS 500000
• CALL LIMIT FOR EXTERNAL TASKS IS 500000
• DBIO LIMIT FOR ONLINE TASKS IS 500000
• DBIO LIMIT FOR EXTERNAL TASKS IS 500000
• LIMITS FOR ONLINE ARE DISABLED

Definição do SYSTEM (Cont)
• LIMITS FOR EXTERNAL ARE DISABLED
• LOADLIST IS SYSLOAD
• MAXIMUM ERUS IS 160
• MAXIMUM TASKS IS 50
• PROGRAM POOL IS 100
• PROTECT
• QUEUE JOURNAL BEFORE
• RELOCATABLE THRESHOLD IS NO
• RETRIEVAL NOLOCK
• RUNAWAY INTERVAL IS 10
• RUNUNITS FOR LOADER = 5
• RUNUNITS FOR SECURITY = 5
• RUNUNITS FOR SIGNON = 5
• RUNUNITS FOR MSGDICT = 5

Definição do SYSTEM (Cont)
• RUNUNITS FOR QUEUE = 5
• RUNUNITS FOR SYSTEM/DEST = 5
• SCRATCH IN STORAGE IS YES
• SNAP SYSTEM IS OFF
• SNAP SYSTEM PHOTO IS OFF
• SNAP TASK IS OFF
• SNAP TASK PHOTO IS OFF
• STATISTICS INTERVAL OFF NOLINE TASK
• COLLECT USER TRANSACTION
• STORAGE KEY IS 9
• SYSLOCKS IS 100000
• SYSTRACE OFF
• TICKER INTERVAL IS 1
• UPDATE NOLOCK

OLQ Commands and Syntax
Use ... To ...
FIND/GET MOST RECENT
Retrieve the current of record type for the specified
record name.
FIND/GET OWNER WITHIN SET Retrieve the owner of a database set occurrence.
FIND/GET PHYSICAL SEQUENTIAL
Retrieve records based on their physical position in a
database area.
FIND/GET using STORAGE KEY
Retrieve records based on their CALC-key or database-
key value.
FIND/GET WITHIN DBKEYLIST
Retrieve records based on the results of previous
retrieval commands.
FIND/GET WITHIN index SET
Retrieve records by using the name of an index set
and the index-sort-key fields specified in the WHERE
clause.
FIND/GET WITHIN SET
Retrieve records based on their membership in a
database set.
FIND/GET WITHIN SET using SORTKEY
Retrieve member records in sorted database sets
based on a specified sort key.
SELECT Retrieve information using the SELECT command.

Processamento em Central Version
• Em um ambiente multiusuário, você usa os serviços de Central Version do
CA IDMS/DC ou CA IDMS UCF para acessar o banco de dados. Quando dois
ou mais usuários tentam acessar ou atualizar o banco de dados
simultaneamente, o SGBD, que faz parte do sistema DC/UCF, controla e
coordena o acesso ao banco de dados. As operações em central version
fornecem maior concorrência e serviços de recuperação do que as
operações em Local Mode.
• Em Central Version:
• O SGBD garante a integridade do banco de dados controlando o acesso simultâneo
por meio de locks que são colocados em áreas, linhas de tabelas ou ocorrencias de
registros.
• O DBMS executa operações de recuperação automática para programas que
terminam de forma anormal.

• Os programas de aplicativos em execução nos seguintes ambientes
podem fazer solicitações de banco de dados da central version:
• Batch address spaces
• Sistemas CA IDMS/DC e CA IDMS UCF (DC/UCF)
• Outros monitores de teleprocessamento (Ex. CICS)
• Um programa aplicativo em execução no ambiente DC/UCF pode
aproveitar as vantagens da arquiterura de Single Region do CA IDMS,
como o banco de dados e os serviços de comunicação de dados
operam em um único address space, as solicitações do banco de
dados não precisam ser transferidas entre diferentes address spaces.

Processamento em Local Mode
• Em Local Mode, o SGBD, que é carregado no momento da execução do
programa, lida com solicitações de serviços de banco de dados, mas não
oferece suporte a solicitações de vários usuários.
• Um programa batch executado em local mode é executado inteiramente
em seu próprio address space.
• Local Mode:
• Reduz a sobrecarga do sistema para Jobs batch de longa execução que tendem a
monopolizar uma área de banco de dados.
• Controla o acesso de aplicativos em local mode em execução simultânea e
aplicativos em central version por meio de bloqueios físicos na área. Apenas um
address space pode atualizar uma área por vez.
• A recuperação em caso de término anormal é realizada por meio de
operações de recuperação manual. Restauração de backups.

Deadlock
• Sempre que a atualização simultânea de um banco de dados ocorrer, é necessário ter um
mecanismo de Lock que evite que 2 ou mais transações atualizem simultaneamente as mesmas
ocorrências de registro. Quando ocorrem contenções por um lock, normalmente a primeira
transação que solicita o recurso obtém acesso a ele, enquanto as transações subsequentes
esperam que a primeira transação libere o bloqueio. Isso pode resultar em uma desaceleração do
processamento e, em situações extremas, algumas das tarefas em espera podem encerrar de
forma anormal devido ao excesso de intervalos de paralisação ou devido às transações envolvidas
entrarem em um abraço mortal, mais comumente referido como um deadlock.
• Um exemplo de um cenário de wait simples em que a transação 1 modifica uma ocorrência de
registro do banco de dados seguida por uma tentativa da transação 2 de acessar a mesma
ocorrência de registro. Nesta situação, a transação 2 aguardará até que a transação 1 libere o lock
do registro, emitindo um comando FINISH ou COMMIT.
• Em um segundo exemplo, vemos que a transação 1 mantém um lock no registro A e precisa
estabelecer um lock no registro B. No entanto, a transação 2 mantém o bloqueio no registro B,
portanto a transação 1 deve esperar. A transação 2 então tenta dar lock no registro A, mas deve
esperar porque a transação 1 já contém um lock nesse registro. O resultado é uma condição de
conflito que só pode ser resolvida encerrando uma das transações.

Deadlock
• Locking error messages:
DC001000 T:852690 APPC P:APXPO031 C:DEAD WAITING ON R:LTXNLOCK 00042009
00397442
DC001001 Txn/RU ID RU NAME SUBSC User ID FE -ID1 FE -ID2 FE -ID3 FE Tskcd
DC001001 451537594 APXPO031 APXSS100 ****
DC001000 T:852711 ADS2 P:APXD1476 C:DEAD WAITING ON R:LTXNLOCK 00052008
008BDB94
DC001001 Txn/RU ID RU NAME SUBSC User ID FE -ID1 FE -ID2 FE -ID3 FE Tskcd
DC001001 451537611 APXD1476 APXSS100 C087415
DC001002 T:852711 ADS2 P:APXD1476 C:DEAD DEADLOCKED ON R:LTXNLOCK
00052008 008BDB94

Abend e Abort
• Use o LOG do IDMS para encontrar o erro e repassar à área responsável, geralmente a área de
desenvolvimento.
• Abend:
Um abend ocorre quando um programa ou uma transação encontra um cenário de erro, como um program
check.
• Abort:
Aborts estão relacionados a diálogos e ocorrem por diversos motivos, como:
• Invalid imput data.
• Invalid record or set name
• DBKEY out of page range
• Page range not found in DMCL
• Duplicates not allowed
• Currency not established
• Area full

Apresentação IDMS DC / DB COMPONENTS RESOURCES

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Apresentação IDMS DC / DB COMPONENTS RESOURCES

Semelhante a Apresentação IDMS DC / DB COMPONENTS RESOURCES (20)

Apresentação IDMS DC / DB COMPONENTS RESOURCES