Dados-chave de contagem - Count key data

Contagem de dados chave ( CKD ) é um formato de gravação de dados de dispositivo de armazenamento de acesso direto (DASD) introduzido em 1964 pela IBM com seu IBM System / 360 e ainda sendo emulado em mainframes IBM. É um formato de autodefinição com cada registro de dados representado por uma área de contagem que identifica o registro e fornece o número de bytes em uma área chave opcional e uma área de dados opcional. Isso está em contraste com dispositivos que usam tamanho de setor fixo ou uma trilha de formato separada.

Dados de chave de contagem (CKD) também se referem ao conjunto de comandos de canal (coletivamente Palavras de Comando de Canal, CCWs) que são gerados por um mainframe IBM para execução por um subsistema DASD empregando o formato de gravação CKD. O conjunto inicial de CCWs CKD, introduzido em 1964, foi substancialmente aprimorado e aprimorado na década de 1990.

Formato de faixa CKD

Diagrama de blocos do formato de rastreamento de dados chave de contagem usado em computadores mainframe IBM, começando com a remessa S / 360 em 1965

"O início de uma trilha é sinalizado quando o marcador de índice (ponto de índice) é detectado. ... O marcador é automaticamente reconhecido por um dispositivo de detecção especial." Seguindo o marcador de índice está o endereço residencial , que indica a localização desta faixa no disco e contém outras informações de controle internas à unidade de controle. Uma lacuna de comprimento fixo segue o endereço residencial. Em seguida, cada trilha contém um Registro 0 (R0), o registro do descritor de trilha, que "é projetado para permitir que todo o conteúdo de uma trilha seja movido para trilhas alternativas se uma parte da trilha principal apresentar defeito". Após R0 estão os blocos de dados, separados por lacunas.

O princípio dos registros CKD é que, uma vez que os comprimentos dos blocos de dados podem variar, cada bloco tem um campo de contagem associado que identifica o bloco e indica o tamanho da chave, se usada (definido pelo usuário até 255 bytes), e o tamanho do área de dados, se usado. O campo de contagem tem a identificação do registro em formato de cabeça de cilindro, o comprimento da chave e o comprimento dos dados. A chave pode ser omitida ou consistir em uma seqüência de caracteres.

Cada registro CKD consiste em um campo de contagem, um campo-chave opcional e um campo de dados opcional do "usuário" com informações de correção / detecção de erros anexadas a cada campo e lacunas que separam cada campo. Por causa das lacunas e outras informações, o espaço registrado é maior do que o necessário apenas para os dados de contagem, dados principais ou dados do usuário. A IBM fornece um "cartão de referência" para cada dispositivo, que pode ser usado para calcular o número de blocos por trilha para vários tamanhos de bloco e para otimizar o tamanho do bloco para o dispositivo. Mais tarde, programas foram escritos para fazer esses cálculos. Como os blocos normalmente não são divididos entre as trilhas, a especificação de um tamanho de bloco incorreto pode desperdiçar até a metade de cada trilha.

Na maioria das vezes, a chave é omitida e o registro é localizado sequencialmente ou por endereçamento direto do registro da cabeça do cilindro. Se estiver presente, a chave é normalmente uma cópia dos primeiros n bytes do registro de dados (para registros "desbloqueados" ou uma cópia da chave mais alta do bloco, para registros "bloqueados"), mas pode ser qualquer dado que será usada para encontrar o registro, geralmente usando a tecla de pesquisa igual ou a tecla de pesquisa alta ou igual CCW. A chave (e, portanto, o registro) pode ser localizada por meio de comandos de hardware. Desde a introdução do System / 360 da IBM em 1964, quase todos os DASDs de sistemas grandes e intermediários da IBM usaram o formato de registro de dados de chave de contagem.

As vantagens do formato de registro de dados-chave de contagem são:

• O tamanho do registro pode ser exatamente igual ao tamanho do bloco do aplicativo
• Os requisitos de CPU e memória podem ser reduzidos explorando os comandos da tecla de pesquisa.
• Os subsistemas IBM CKD operaram inicialmente de forma síncrona com o canal do sistema e podem processar informações nas lacunas entre os vários campos, alcançando assim um desempenho superior, evitando a transferência redundante de informações para o host. As operações síncronas e assíncronas são suportadas em subsistemas posteriores.

Os preços reduzidos de CPU e memória e velocidades de dispositivo e interface mais altas anularam de alguma forma as vantagens do CKD, e ele é mantido apenas porque o principal sistema operacional z / OS da IBM não oferece suporte a interfaces orientadas a setores.

Originalmente, os registros CKD tinham uma correspondência um a um com uma trilha física de um dispositivo DASD; no entanto, com o tempo, os registros tornaram-se cada vez mais virtualizados, de modo que nos mainframes IBM modernos não há mais correspondência direta entre o ID de um registro CKD e o layout físico de uma pista.

Subsistemas CKD DASD da IBM

IBM S / 360 e S / 370 Input / Output operações para CKD DASD mostrando canal, unidade de controle de armazenamento e dispositivo DASD

Programação

O acesso a classes específicas de dispositivos de I / O por um mainframe IBM está sob o controle de Channel Command Words (CCWs), alguns dos quais são genéricos (por exemplo, nenhuma operação), mas muitos dos quais são específicos para o tipo de dispositivo de I / O ( por exemplo, ler para trás para uma unidade de fita). O grupo de CCWs definido pela IBM para DASD se enquadra em cinco categorias amplas:

• Controle  - controle do DASD, incluindo o caminho para o mesmo
• Sentido  - status de sentido do DASD, incluindo o caminho para ele; alguns comandos de sentido afetam o status do controlador e DASD de uma forma mais compatível com um comando de controle, por exemplo, RESERVE, RELEASE
• Gravar  - gravar informações no controlador ou DASD (que pode ser armazenado em buffer ou em cache no caminho)
• Pesquisa  - compare as informações da CPU com as informações armazenadas no DASD; o canal opera no modo de gravação enquanto a unidade de armazenamento opera no modo de leitura.
• Ler  - ler informações do DASD (que pode ser armazenado em buffer ou em cache no caminho)

CKD CCWs são o conjunto específico de CCWs usados ​​para acessar subsistemas CKD DASD. Isso está em contraste com os CCWs de arquitetura de bloco fixo (FBA) que são usados ​​para acessar subsistemas FBA DASD.

CKD DASD são endereçados como outros dispositivos de entrada / saída; para System / 360 e System / 370 DASD são endereçados diretamente, através de canais e das unidades de controle associadas (SCU ou Unidade de Controle de Armazenamento), inicialmente usando três dígitos hexadecimais, um para canal e dois para unidade de controle e dispositivo, fornecendo endereçamento para até 16 canais, para até 256 mecanismos / canal de acesso DASD e 4.096 endereços DASD no total. Os mainframes IBM modernos usam quatro dígitos hexadecimais como um número de subcanal arbitrário dentro de um subconjunto de subsistema de canal, cuja definição inclui os canais reais, unidades de controle e dispositivo, fornecendo endereçamento para até 65.536 DASD por subconjunto de subsistema de canal. Na prática, as restrições físicas e de design do canal e dos controladores limitaram o número máximo de DASD anexado anexado a um sistema a uma quantidade menor do que o número que poderia ser endereçado.

Embalagem

Inicialmente, havia um alto grau de correspondência entre a visão lógica dos acessos DASD e o hardware real, conforme mostrado na ilustração acima. Etiquetas de três dígitos normalmente eram afixadas para identificar o endereço do canal, unidade de controle e dispositivo.

Em sistemas low end, o Canal e a Unidade de Controle eram frequentemente integrados fisicamente, mas permaneciam logicamente separados. A nova estratégia de conexão da IBM, começando com o 3830 Modelo 2 em 1972, separou fisicamente a SCU em duas entidades físicas, um diretor e um controlador, mantendo-os logicamente iguais. O controlador lida com a formatação da trilha CKD e é embalado com a primeira unidade ou unidades em uma série de unidades e tendo um número de modelo com a letra "A" como prefixo, uma "Unidade A" (ou "A-Box") como no 3350 Modelo A2 contendo um controlador e dois DASDs. O DASD sem controlador, ou seja, unidades B, tem um prefixo "B" no número do modelo.

Subsistemas e diretores CKD foram oferecidos pela IBM e concorrentes compatíveis com plugue até pelo menos 1996 (2301 a 3390 Modelo 9); no total, 22 DASD exclusivos oferecidos pela IBM, configurados em pelo menos 35 configurações de subsistema diferentes . Plug-compatível oferece muitos dos mesmos DASD, incluindo 4 subsistemas CKD com DASD exclusivo.

Conjunto inicial de recursos CKD

O conjunto de recursos inicial fornecido pela IBM com sua introdução em 1964 do formato de trilha CKD e CCWs associados incluiu:.

• Pista Defeituosa / Alternativa  - ativa uma pista alternativa para substituir uma pista defeituosa transparente ao método de acesso em uso.
• Estouro de  registro - os registros podem exceder o comprimento máximo da trilha de um DASD
• Operações multitrack  - CCWs específicos podem continuar para a próxima cabeça sequencial
• Encadeamento de comandos  - os CCWs podem ser encadeados para construir programas de canal complexos. As lacunas em um formato de trilha CKD fornecem tempo suficiente entre os comandos de forma que todo o canal e a atividade SCU necessária para completar um comando possam ser realizadas em uma lacuna entre os campos apropriados. Esses programas podem pesquisar uma grande quantidade de informações armazenadas em um DASD, após a conclusão bem-sucedida, retornando apenas os dados desejados e, assim, liberando recursos da CPU para outras atividades. Este modo de operação em sincronia com a lacuna foi posteriormente aprimorado por CCWs adicionais, permitindo um modo de operação não síncrono .
• Troca de canal  - uma SCU pode ser compartilhada entre canais - inicialmente foi fornecida a troca de dois canais e foi expandida para até oito canais nas SCUs posteriores. Os canais podem estar no mesmo CPUS ou em diferentes.

Um conjunto de recursos de varredura também foi fornecido, mas não continuou em subsistemas CKD futuros além do 2314.

Quarenta e um CCWs implementaram o conjunto de recursos:

Notas:

O = recurso opcional

S = recurso padrão

MT = multitrack: quando suportado CCW continuará a operar nas próximas cabeças na sequência até o fim do cilindro

‡ = TIC (Transfer In Channel) e outros comandos padrão não mostrados.

† = código igual ao MT Off, exceto conforme listado

1. Recurso de digitalização de arquivo (9 CCWs) disponível apenas em 2841 para 2302, 2311 e 2321; eles não estavam disponíveis em controladores DASD subsequentes para DASD posteriores a 2314.

2. A contagem é o número de bytes no argumento de pesquisa, incluindo bytes de máscara

Os CCWs foram inicialmente executados por dois tipos de SCU anexados aos canais seletores de alta velocidade do sistema . O 2820 SCU controlava o 2301 Drum enquanto o 2841 SCU controlava as combinações do 2302 Disk Storage , 2311 Disk Drive, 2321 Data Cell e / ou 7320 Drum Storage. A IBM rapidamente substituiu o 7320 pelo 2303 mais rápido e maior.

Posteriormente, o conjunto de recursos foi implementado na família 2314 de controles de armazenamento e um anexo integrado do Sistema 370 Modelo 25 .

O exemplo a seguir de um programa de canal lê um registro de disco identificado por um campo Chave. A faixa que contém o registro e o valor desejado da chave são conhecidos. O SCU irá pesquisar a pista para encontrar o registro solicitado. Neste exemplo, <> indica que o programa do canal contém o endereço de armazenamento do campo especificado.

  SEEK             <cylinder/head number>
  SEARCH KEY EQUAL <key value>
  TIC              *-8 Back to search if not equal
  READ DATA        <buffer> 

O TIC (transferência no canal) fará com que o programa do canal desvie para o comando SEARCH até que um registro com uma chave correspondente (ou o fim da trilha) seja encontrado. Quando um registro com uma chave correspondente é encontrado, o SCU incluirá o Modificador de Status no status do canal, fazendo com que o canal ignore o TIC CCW; assim, o programa do canal não se ramificará e o canal executará o comando READ.

Aprimoramentos de canal de multiplexador de bloco

O canal do multiplexador de bloco foi introduzido no início de 1971 em alguns sistemas System / 360 de ponta junto com a Unidade de Controle 2835 e DASD 2305 associado. Esse canal era então padrão no IBM System / 370 e mainframes subsequentes; quando contrastado com o canal Selector anterior, ele ofereceu melhorias de desempenho para dispositivos de alta velocidade, como DASD, incluindo:

Solicitando Múltiplos

Permitia que programas de vários canais estivessem ativos simultaneamente na instalação, em oposição a apenas um com um canal Seletor. O número real de subcanais fornecidos depende do modelo do sistema e de sua configuração. Às vezes descrito como encadeamento de comando desconectado, a unidade de controle pode se desconectar várias vezes durante um conjunto encadeado de CCWs, por exemplo, desconexão para um CCW de busca, liberando o canal para outro subcanal.

Tentar Comando

O canal e o controle de armazenamento sob certas condições podem interoperar para fazer com que um CCW seja tentado novamente sem uma interrupção de E / S. Este procedimento é iniciado pelo controle de armazenamento e usado para se recuperar de erros corrigíveis.

Sensor de posição rotacional

O sensor de posição rotacional (RPS) foi implementado com dois novos CCWs, SET SECTOR e READ SECTOR habilitaram o canal para atrasar o encadeamento de comandos até que o disco girasse para uma posição angular especificada da trilha. O RPS permite a desconexão do canal durante a maior parte do período de atraso rotacional e, portanto, contribui para o aumento da utilização do canal. A unidade de controle implementa RPS dividindo cada trilha em segmentos angulares iguais.

Exemplo de programa de canal

O programa de canal de exemplo a seguir formatará uma faixa com um R0 e três registros CKD.

  SEEK             <cylinder/head number>
  SET FILE MASK    <allow write operations>
  SET SECTOR       <sector number=0>
  WRITE R0         <cylinder/head/R0, key length=0, data length=6>
  WRITE CKD        <cylinder/head/R1, key length, data length>
  WRITE CKD        <cylinder/head/R2, key length, data length>
  WRITE CKD        <cylinder/head/R3, key length, data length>  

Neste exemplo, o Registro 0 está em conformidade com os padrões de programação da IBM. Com um canal de multiplexador de bloco, o canal está livre durante o tempo em que o DASD está procurando e novamente enquanto o disco gira para o início da trilha. Um canal seletor ficaria ocupado durante toda a duração deste programa de amostra.

Salto de defeito

O salto de defeito permite que os dados sejam gravados antes e depois de um ou mais defeitos de superfície, permitindo que toda a trilha seja usada, exceto para a parte que tem o defeito. Isso também elimina o tempo que antes era necessário para buscar uma pista alternativa. Apenas um número limitado de defeitos pôde ser ignorado, de modo que as trilhas alternativas permaneceram com suporte para as trilhas com defeitos excessivos.

A omissão de defeitos foi introduzida em 1974 com o 3340 conectado por meio da Unidade de Controle de Armazenamento Modelo 2 3830 ou acessórios integrados em sistemas pequenos. A omissão de defeitos era essencialmente um recurso exclusivo de fábrica até 1981, quando os CCWs para gerenciamento junto com os utilitários associados foram lançados.

Caminhos dinâmicos

Apresentado pela primeira vez com o 3380 DASD na Unidade de Controle de Armazenamento 3880 em 1981, o recurso foi incluído com os subsistemas CKD DASD posteriores. A função de seleção de caminho dinâmico controla a operação dos dois controladores, incluindo a transferência simultânea de dados pelos dois caminhos. Quando compatível com o sistema operacional, cada controlador pode servir como um caminho alternativo caso o outro controlador não esteja disponível.

Três comandos adicionais, Set Path Group ID, Sense Path Group ID e Suspend Multipath Reconnection, são usados ​​para suportar a conexão dos Modelos 3380 com dois controladores no início de uma string.

O comando Set Path Group ID, com a função de seleção dinâmica de caminho (DPS), oferece maior flexibilidade nas operações em dispositivos reservados. Uma vez que um grupo de caminhos para um dispositivo tenha sido estabelecido, ele pode ser acessado por qualquer caminho que seja membro do grupo para o qual está reservado. Além disso, em sistemas 370-XA que definem o bit de modo multipath no byte de controle de função (byte 0) para 1, as reconexões multiplex de bloco ocorrerão no primeiro caminho disponível que é um membro do grupo sobre o qual o programa de canal foi iniciada (independentemente do estado de reserva do dispositivo).

Se o controlador designado no endereço de E / S estiver ocupado ou desabilitado, a seleção do caminho dinâmico permite que um caminho alternativo para o dispositivo seja estabelecido por meio de outro diretor de armazenamento e o outro controlador no modelo AA.

Operação não síncrona

Antes da introdução do diretor 3880 em 1981, os registros CKD eram acessados ​​de forma síncrona, todas as atividades exigiam que um CCW fosse encerrado e o próximo iniciado nas lacunas entre os campos CKD. O tamanho do intervalo colocava limitações no comprimento do cabo, mas proporcionava um desempenho muito alto, uma vez que cadeias complexas de CCWs podiam ser executadas pelo subsistema em tempo real sem o uso de memória ou ciclos da CPU.

A operação não síncrona fornecida pelo conjunto de CCWs Extended CKD ("ECKD") removeu a restrição de intervalo de tempo. Os cinco ECKD CCWs adicionais são Definir Extensão, Localizar Registro, Gravar Dados de Atualização, Gravar Chave e Dados de Atualização e Gravar Próxima Faixa de CKD.

Na operação não síncrona, a transferência de dados entre o canal e o controle de armazenamento não é sincronizada com a transferência de dados entre o controle de armazenamento e o dispositivo. Os programas de canal podem ser executados de modo que as atividades de controle de canal e armazenamento necessárias para encerrar a execução de um comando e avançar para o próximo não precisem ocorrer durante o intervalo entre registros entre dois campos adjacentes. Um buffer intermediário no controle de armazenamento permite operações independentes entre o canal e o dispositivo. Uma grande vantagem dos ECKDs são cabos muito mais longos; dependendo da aplicação, pode melhorar o desempenho.

ECKD CCWs são suportados em todos os subsistemas CKD subsequentes.

Este programa de canal não síncrono de exemplo lê os registros R1 e R2 da trilha X'0E 'no cilindro X'007F'. Ambos os registros têm um comprimento de chave de 8 e um comprimento de dados de X'64 '(100 ₁₀ ) bytes.

  Define Extent       <extent= X'007F 0000' through track X'0081 000E'>
  Locate Record       <cylinder = X'007F', head = X'000E'
  Read Key and Data   <key record = X'001038'>
  Read Data           <record = X'001108'>

Cache

O cache introduzido pela primeira vez nos subsistemas DASD CKD por Memorex (1978) e StorageTek (1981) foi posteriormente introduzido no final de 1981 pela IBM no 3880 Modelo 13 para modelos do 3380 com caminho dinâmico.

O cache é gerenciado dinamicamente por um algoritmo; os dados de alta atividade são acessados ​​do cache de alto desempenho e os dados de baixa atividade são acessados ​​do armazenamento DASD mais barato. Uma grande memória no Director, o cache, é dividida em slots de trilha que armazenam dados das 3380 trilhas. Uma área menor é um diretório que contém entradas que permitem que os dados sejam localizados no cache.

Caches também foram fornecidos em controles de armazenamento introduzidos posteriormente.

Outras extensões

Com o tempo, vários CCWs de controle de caminho, diagnóstico e / ou recuperação de erro foram implementados em um ou mais controles de armazenamento. Por exemplo:

• A Reserva Incondicional permitia a liberação de um dispositivo reservado para outro canal e a reserva do dispositivo para o canal que emitiu o comando.
• Ler dados-chave de contagem múltipla pode ler faixas completas com mais eficiência, permitindo backups mais eficientes.

Além do Sistema / 370

Os preços reduzidos de CPU e memória e velocidades mais altas de dispositivo e interface anularam um pouco as vantagens do CKD, e o suporte continua da IBM até hoje porque seu principal sistema operacional z / OS continua a usar CCWs CKD para muitas funções.

Originalmente, os registros CKD tinham uma correspondência um a um com uma trilha física de um dispositivo DASD; no entanto, com o tempo, os registros se tornaram cada vez mais virtualizados, de modo que em um mainframe IBM moderno não há mais correspondência direta entre o ID de um registro CKD e o layout físico de uma pista. Um mainframe IBM constrói imagens de trilha CKD na memória e executa os programas de canal ECKD e CKD na imagem. Para fazer a ponte entre os discos de tamanho de bloco fixo nativo e o formato de registro ECKD / CKD de comprimento variável, as imagens de trilha CKD na memória são mapeadas em uma série de blocos fixos adequados para transferência de e para um subsistema de disco FBA.

Dos 83 CCWs CKD implementados para os canais System / 360 e System / 370, 56 são emulados no System / 390 e sistemas posteriores.

Veja também

• Bloco (armazenamento de dados)
• Conjunto de dados (mainframe IBM)
• Arquitetura de bloco fixo (FBA)
• Registro (ciência da computação)
• Faixa (unidade de disco)
• Índice de Volume (VTOC)

Notas

Referências

Leitura adicional

• IBM Data Processing Division (fevereiro de 1974). Introdução aos dispositivos de armazenamento de acesso direto IBM e métodos de organização (PDF) (décima ed.). White Plains: International Business Machines. OCLC   8063006 . GC20-1649-9 . Retirado em 6 de agosto de 2014 .
• Development of 360/370 Architecture - A Plain Man's View PJ Gribbin, 10 de fevereiro de 1989, capítulos 8–10.