Telle nøkkeldata - Count key data

Count key data ( CKD ) er et dataopptaksformat for direkte tilgang lagringsenhet (DASD) som ble introdusert i 1964, av IBM med IBM System / 360 og fortsatt emulert på IBMs hovedrammer. Det er et selvdefinerende format med hver datapost representert av et Count Area som identifiserer posten og gir antall byte i et valgfritt nøkkelområde og et valgfritt dataområde. Dette er i motsetning til enheter som bruker fast sektorstørrelse eller et eget formatspor.

Count key data (CKD) refererer også til settet med kanalkommandoer (samlet Channel Command Words, CCWs) som genereres av en IBM-hovedramme for utføring av et DASD-undersystem som benytter CKD-opptaksformatet. Det første settet med CKD CCW-er, introdusert i 1964, ble betydelig forbedret og forbedret til 1990-tallet.

CKD-sporformat

Blokkdiagram over antall nøkkeldata sporformat brukt på IBM mainframe datamaskiner som begynner med S / 360 forsendelse i 1965

"Begynnelsen på et spor signaliseres når indeksmarkøren (indekspunktet) oppdages. ... Markøren gjenkjennes automatisk av en spesiell sensorenhet." Etter indeksmarkøren følger hjemmeadressen , som indikerer plasseringen av dette sporet på disken, og inneholder annen kontrollinformasjon internt til kontrollenheten. Et gap med fast lengde følger hjemmeadressen. Deretter inneholder hvert spor en post 0 (R0), sporbeskrivelsesposten, som er "designet for å muliggjøre at hele innholdet i et spor kan flyttes til alternative spor hvis en del av primærsporet blir defekt." Etter R0 er datablokkene, atskilt med hull.

Prinsippet med CKD-poster er at siden datablokklengder kan variere, har hver blokk et tilhørende tellefelt som identifiserer blokken og indikerer størrelsen på nøkkelen, hvis den brukes (brukerdefinert opptil 255 byte), og størrelsen på dataområdet, hvis det brukes. Tellefeltet har identifikasjon av posten i sylinderhode-postformat, lengden på nøkkelen og lengden på dataene. Nøkkelen kan utelates eller bestå av en streng med tegn.

Hver CKD-post består av et tellefelt, et valgfritt nøkkelfelt og et valgfritt "bruker" -datafelt med feilretting / deteksjonsinformasjon vedlagt hvert felt og hull som skiller hvert felt. På grunn av hullene og annen informasjon er den registrerte plassen større enn det som kreves for bare telledata, nøkkeldata eller brukerdata. IBM tilbyr et "referansekort" for hver enhet, som kan brukes til å beregne antall blokker per spor for forskjellige blokkstørrelser, og for å optimalisere blokkstørrelsen for enheten. Senere ble det skrevet programmer for å gjøre disse beregningene. Fordi blokker normalt ikke er delt mellom spor, kan spesifikasjon av feil blokkstørrelse kaste bort opptil halvparten av hvert spor.

Som oftest blir nøkkelen utelatt, og posten lokaliseres sekvensielt eller ved direkte adressering av sylinderhodet. Hvis den er tilstede, er nøkkelen vanligvis en kopi av de første n byte av dataposten (for "ikke-blokkerte" poster, eller en kopi av den høyeste nøkkelen i blokken, for "blokkerte" poster), men kan være hvilken som helst data som vil bli brukt til å finne posten, vanligvis ved å bruke Søke nøkkel lik eller Søke nøkkel høy eller lik CCW. Nøkkelen (og dermed posten) er lokaliserbar via maskinvarekommandoer. Siden introduksjonen av IBMs System / 360 i 1964 har nesten alle DASD- er for store og mellomstore IBM- maskiner brukt telleopplysningsformatet .

Fordelene med count key data record format er:

• Rekordstørrelsen kan være nøyaktig tilpasset applikasjonsblokkstørrelsen
• CPU- og minnekrav kan reduseres ved å utnytte kommandoer for søketastene.
• IBM CKD-undersystemer startet i utgangspunktet synkront med systemkanalen og kan behandle informasjon i hullene mellom de forskjellige feltene, og derved oppnå høyere ytelse ved å unngå overflødig overføring av informasjon til verten. Både synkrone og asynkrone operasjoner støttes på senere delsystemer.

Reduserte CPU- og minnepriser og høyere enhets- og grensesnitthastigheter har noe opphevet fordelene med CKD, og ​​det beholdes bare fordi IBMs flaggskip-operativsystem z / OS ikke støtter sektororienterte grensesnitt.

Opprinnelig hadde CKD-poster en en-til-en korrespondanse med et fysisk spor av en DASD-enhet; men over tid har postene blitt mer og mer virtualisert slik at det i moderne IBM-hovedrammer ikke lenger er en direkte samsvar mellom en CKD-post-ID og et fysisk oppsett av et spor.

IBMs CKD DASD-delsystemer

IBM S / 360 & S / 370 Inngang / utgang for CKD DASD som viser kanal, lagringskontrollenhet og DASD-enhet

Programmering

Tilgang til spesifikke klasser av I / O-enheter fra en IBM-hovedramme er under kontroll av Channel Command Words (CCWs), hvorav noen er generiske (f.eks. Ingen betjening), men mange av dem er spesifikke for typen I / O-enhet ( Les f.eks. bakover for en båndstasjon). Gruppen CCW definert av IBM for DASD faller inn i fem brede kategorier:

• Kontroll  - kontroll av DASD inkludert stien til den
• Sense  - følelsesstatus for DASD inkludert stien til det; noen sansekommandoer påvirker statusen til kontrolleren og DASD på en måte som er mer i tråd med en kontrollkommando, f.eks. RESERVE, RELEASE
• Skriv  - skriv informasjon til kontrolleren eller DASD (som kan være bufret eller bufret i banen)
• Søk  - sammenlign informasjon fra CPUen med informasjon lagret i DASD; kanalen fungerer i skrivemodus mens lagringsenheten fungerer i lesemodus.
• Les  - les informasjon fra DASD (som kan være bufret eller bufret i banen)

CKD CCW er det spesifikke settet med CCW som brukes for å få tilgang til CKD DASD-delsystemer. Dette er i motsetning til fast blokk arkitektur (FBA) CCWs som brukes til å få tilgang FBA DASD delsystemer.

CKD DASD adresseres som andre Input / Output-enheter; for System / 360 og System / 370 DASD adresseres direkte, gjennom kanaler og tilhørende kontrollenheter (SCU eller Storage Control Unit), ved å bruke tre heksadesimale sifre, en for kanal og to for kontrollenhet og enhet, og gir adressering til opptil 16 kanaler, for opptil 256 DASD-tilgangsmekanismer / kanal og 4096 DASD-adresser totalt. Moderne IBM-hovedrammer bruker fire heksadesimale sifre som et vilkårlig underkanalnummer i et delsystem for kanalundersystem, hvis definisjon inkluderer de faktiske kanalene, kontrollenhetene og enheten, og gir adressering for opptil 65.536 DASD per delsystem for delsystem for kanaler. I praksis begrenset fysiske og designmessige begrensninger for kanalen og kontrollerne det maksimale antallet tilkoblede DASD som kan kobles til et system til et mindre beløp enn antallet som kan adresseres.

Emballasje

Opprinnelig var det en høy grad av samsvar mellom det logiske synet på DASD-tilgang og den faktiske maskinvaren, som vist i illustrasjonen ovenfor. Tre-sifrede etiketter ble vanligvis festet for å identifisere adressen til kanalen, kontrollenheten og enheten.

På low-end-systemer ble Channel og Control Unit ofte fysisk integrert, men forble logisk. IBMs nye vedleggsstrategi som begynte med 3830 Model 2 i 1972, separerte SCU fysisk i to fysiske enheter, en regissør og en kontroller samtidig som de holdt dem logisk. Kontrolleren håndterer CKD-sporformatering og er pakket med den første stasjonen eller stasjoner i en streng stasjoner og har et modellnummer med bokstaven "A" som prefiks, en "A-enhet" (eller "A-Box") som i 3350 modell A2 som inneholder en kontroller og to DASD-er. DASD uten kontroller, det vil si B-enheter, har et "B" prefiks i modellnummeret.

CKD-delsystemer og regissører ble tilbudt av IBM og støtter kompatible konkurrenter til minst 1996 (2301 til 3390 modell 9); totalt 22 unike DASD tilbys av IBM konfigurert i minst 35 forskjellige delsystemkonfigurasjoner . Plug-kompatibel tilbys mange av samme DASD inkludert 4 CKD-undersystemer med unike DASD.

Innledende CKD-funksjonssett

Det innledende funksjonssettet som ble levert av IBM med sin introduksjon av CKD - ​​sporformatet i 1964 og tilhørende CCW - er inkludert:.

• Defekt / alternativt spor  - gjør det mulig for et alternativt spor å erstatte et defekt spor som er gjennomsiktig for tilgangsmetoden som er i bruk.
• Record overflow  - poster kan overstige maksimal sporlengde for en DASD
• Multitrack-operasjoner  - spesifikke CCW-er kan fortsette til neste sekvensielle hode
• Kommandokjetting  - CCW kan lenkes sammen for å konstruere komplekse kanalprogrammer. Hullene i et CKD-sporformat ga tilstrekkelig tid mellom kommandoene, slik at all kanal- og SCU-aktivitet som er nødvendig for å fullføre en kommando, kan utføres i spalten mellom passende felt. Slike programmer kan søke i en stor mengde informasjon som er lagret på en DASD, etter vellykket fullføring, bare returnere de ønskede dataene og derved frigjøre CPU-ressurser for annen aktivitet. Denne modusen for å drive synkront til gapet ble senere forbedret av flere CCW-er som muliggjorde en ikke- synkron modus for drift .
• Kanalsvitsjing  - en SCU kan deles mellom kanaler - i utgangspunktet ble to kanalsvitsjing gitt, og den ble utvidet til opptil åtte kanaler i senere SCUer. Kanalene kan være på samme eller forskjellige CPUS.

Et skannefunksjonssett ble også levert, men ble ikke videreført i fremtidige CKD-delsystemer utover 2314.

Førti CCWs implementerte funksjonssettet:

Merknader:

O = valgfri funksjon

S = standard funksjon

MT = multitrack: når det støttes, fortsetter CCW å operere på neste hoder i rekkefølge til slutten av sylinderen

‡ = TIC (Transfer In Channel) og andre standardkommandoer som ikke vises.

† = kode samme som MT Off bortsett fra som oppført

1. File Scan Feature (9 CCWs) bare tilgjengelig på 2841 for 2302, 2311 og 2321; de var ikke tilgjengelige på påfølgende DASD-kontrollere for DASD senere enn 2314.

2. Count er antall byte i søkeargumentet, inkludert maskebyte

De CCWs ble først ble utført av to typer av SCU festet til systemets høy hastighet velgerkanal . Den 2820 SCU kontrollerte 2301 Drum mens 2841 SCU kontrollerte kombinasjoner av 2302 Disk Storage , 2311 Disk Drive, 2321 datacelle og / eller 7320 Drum Storage. IBM byttet raskt ut 7320 med raskere og større 2303.

Deretter ble funksjonssettet implementert i 2314-familien av lagringskontroller og et integrert vedlegg av System 370 Model 25 .

Følgende eksempel på et kanalprogram leser en diskoppføring identifisert av et nøkkelfelt. Sporet som inneholder posten og ønsket verdi av nøkkelen er kjent. SCU vil søke i sporet for å finne den forespurte posten. I dette eksemplet <> angir at kanalprogrammet inneholder lagringsadressen til det angitte feltet.

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

TIC (overføring i kanal) vil føre til at kanalprogrammet forgrener seg til SEARCH-kommandoen til en plate med en matchende nøkkel (eller slutten av sporet) oppstår. Når en post med en matchende nøkkel blir funnet, vil SCU inkludere Status Modifier i kanalstatusen, og føre til at kanalen hopper over TIC CCW; Dermed vil ikke kanalprogrammet forgrene seg, og kanalen vil utføre READ-kommandoen.

Blokker kanalforbedringer for multiplekser

Den blokk multiplekser kanal ble innført som begynner i 1971 på noen high end System / 360-systemer sammen med 2835 kontrollenheten og tilhørende 2305 DASD, Denne kanalen ble deretter standard på IBM System / 370 og senere stormaskiner; når det var i motsetning til den tidligere Selector-kanalen, tilbød den ytelsesforbedringer for høyhastighetsenheter som DASD, inkludert:

Flere forespørsler

Tillatt flere kanalprogrammer, å være samtidig aktive i anlegget i motsetning til bare ett med en Selector-kanal. Det faktiske antallet underkanaler som tilbys avhenger av systemmodellen og konfigurasjonen. Noen ganger beskrevet som frakoblet kommandokjetting, kunne kontrollenheten koble fra på forskjellige tidspunkter under et lenket sett med CCW, for eksempel frakobling for en Seek CCW, og frigjøre kanalen for en annen underkanal.

Kommando på nytt

Kanalen og lagringskontrollen under visse forhold kan fungere sammen for å få en CCW til å bli prøvd på nytt uten et I / O-avbrudd. Denne prosedyren startes av lagringskontrollen og brukes til å gjenopprette fra korrigerbare feil.

Rotasjonsposisjonssensing

Rotasjonsposisjonsregistrering (RPS) ble implementert med to nye CCW-er, SET SECTOR og READ SECTOR gjorde det mulig for kanalen å forsinke kommandokjetting til disken roterte til en spesifisert vinklet sporposisjon. RPS tillater frakobling av kanaler under det meste av rotasjonsforsinkelsesperioden og bidrar dermed til økt kanalutnyttelse. Kontrollenheten implementerer RPS ved å dele hvert spor i like vinkelsegmenter.

Eksempel på kanalprogram

Følgende eksempel på kanalprogram vil formatere et spor med en R0 og tre CKD-poster.

  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>  

I dette eksemplet er post 0 i samsvar med IBMs programmeringsstandarder. Med en blokkmultiplekserkanal er kanalen ledig i løpet av den tiden DASD søker og igjen mens disken roterer til begynnelsen av sporet. En velgerkanal vil være opptatt i hele dette prøveprogrammets varighet.

Feilhopp

Feilspring lar data skrives før og etter en av flere overflatefeil som gjør at hele sporet kan brukes bortsett fra den delen som har feilen. Dette eliminerer også tiden som tidligere var nødvendig for å søke til et alternativt spor. Bare et begrenset antall feil kunne hoppes over, så alternative spor forble støttet for de sporene med overflødige feil.

Hopp over mangler ble introdusert i 1974 med 3340 festet via 3830 Model 2 Storage Control Unit eller integrerte vedlegg på små systemer. Hopp over mangler var egentlig en eneste fabrikkfunksjon frem til 1981 da CCW-er for ledelse sammen med tilhørende verktøy ble utgitt.

Dynamiske stier

Først introdusert med 3380 DASD på 3880 Storage Control Unit i 1981, ble funksjonen inkludert i de senere CKD DASD-delsystemene. Funksjonen for valg av dynamisk vei styrer driften av de to kontrollerne, inkludert samtidig dataoverføring over de to banene. Når det støttes av operativsystemet, kan hver kontroller fungere som en alternativ bane i tilfelle den andre kontrolleren ikke er tilgjengelig.

Tre ekstra kommandoer, Set Path Group ID, Sense Path Group ID, and Suspend Multipath Reconnection, brukes til å støtte vedlegg av 3380-modellene som har to kontrollere på hodet til en streng.

Kommandoen Set Path Group ID, med DPS-funksjonen (Dynamic Path Selection) gir større fleksibilitet i operasjoner på reserverte enheter. Når en stygruppe for en enhet er opprettet, kan den nås over hvilken som helst sti som er medlem av gruppen den er reservert til. I tillegg, på 370-XA-systemer som setter flerveismodusbit i funksjonskontrollbyte (byte 0) til 1, vil blokkmultipleks-rekoblinger forekomme på den første tilgjengelige banen som er medlem av gruppen som kanalprogrammet var over. startet (uavhengig av enhetens reservasjonstilstand).

Hvis kontrolleren som er angitt i I / O-adressen er opptatt eller deaktivert, tillater det dynamiske banevalget at en alternativ bane til enheten kan etableres via en annen lagringsdirektør og den andre kontrolleren i modellen AA.

Ikke-synkron drift

Før 1981-introduksjonen av 3880-direktøren ble CKD-poster synkronisert, alle aktiviteter krevde at en CCW ble avsluttet og den neste startet i hullene mellom CKD-feltene. Avstandsstørrelsen satte begrensninger på kabellengden, men sørget for veldig høy ytelse, siden komplekse kjeder av CCW-er kunne utføres av delsystemet i sanntid uten bruk av CPU-minne eller sykluser.

Ikke-synkron operasjon levert av utvidet CKD ("ECKD") sett med CCW fjernet tidsbegrensningen for gap. De fem ekstra ECKD CCW-ene er Define Extent, Locate Record, Write Update Data, Write Update Key and Data, and Write CKD Next Track.

I ikke-synkron drift synkroniseres ikke overføringen av data mellom kanalen og lagringskontrollen med overføringen av data mellom lagringskontrollen og enheten. Kanalprogrammer kan utføres slik at kanal- og lagringskontrollaktiviteter som kreves for å avslutte utførelsen av en kommando og gå videre til den neste, ikke trenger å forekomme i løpet av mellomregistreringsgapet mellom to tilstøtende felt. En mellombuffer i lagringskontrollen tillater uavhengige operasjoner mellom kanalen og enheten. En stor fordel med ECKD er langt lengre kabler; avhengig av applikasjon kan det forbedre ytelsen.

ECKD CCW-er støttes på alle påfølgende CKD-delsystemer.

I dette eksemplet leses ikke-synkront kanalprogram poster R1 og R2 fra spor X'0E 'i sylinder X'007F'. Begge postene har en nøkkelengde på 8 og en datalengde på X'64 '(100 ₁₀ ) byte.

  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'>

Caching

Caching ble først introdusert i DASD CKD-undersystemer av Memorex (1978) og StorageTek (1981) ble deretter introdusert i slutten av 1981 av IBM på 3880 Model 13 for modeller av 3380 med dynamisk pathing.

Cachen administreres dynamisk av en algoritme; data med høy aktivitet er tilgjengelig fra hurtigyteminnet med høy ytelse, og data om lavaktivitet er tilgjengelig fra billigere DASD-lagring. Et stort minne i Director, cachen, er delt inn i spor spor som lagrer data fra 3380 spor. Et mindre område er en katalog som inneholder oppføringer som gjør at data kan plasseres i hurtigbufferen.

Cacher ble også gitt på senere innførte lagringskontroller.

Andre utvidelser

Over tid ble det implementert en rekke banekontroll-, diagnostiske og / eller feilgjenopprettings-CCW-er på en eller flere lagringskontroller. For eksempel:

• Ubetinget reserve tillot å frigjøre en enhet som er reservert til en annen kanal og reservere enheten til kanalen som utsteder kommandoen.
• Les flere nøkkeldata kan mer effektivt lese fullstendige spor, noe som gir mer effektive sikkerhetskopier.

Utover System / 370

Reduserte CPU- og minnepriser og høyere enhets- og grensesnitthastigheter har noe opphevet fordelene med CKD, og ​​støtten fortsetter av IBM til denne datoen fordi flaggskipets operativsystem z / OS fortsetter å bruke CKD CCW for mange funksjoner.

Opprinnelig hadde CKD-poster en en-til-en korrespondanse med et fysisk spor av en DASD-enhet; men over tid har postene blitt mer og mer virtualisert slik at det i en moderne IBM-hovedramme ikke lenger er en direkte samsvar mellom en CKD-post-ID og en fysisk layout av et spor. En IBM-hovedramme konstruerer CKD-sporbilder i minnet og utfører ECKD- og CKD-kanalprogrammene mot bildet. For å bygge bro mellom de opprinnelige diskene med fast blokkstørrelse og ECKD / CKD-postformatet med variabel lengde, blir CKD-sporbildene i minnet kartlagt på en serie faste blokker som er egnet for overføring til og fra et FBA-diskundersystem.

Av de 83 CKD CCW-ene som er implementert for System / 360 og System / 370-kanaler 56 er emulert på System / 390 og senere systemer.

Se også

• Blokker (datalagring)
• Datasett (IBM-hovedramme)
• Fastblokkarkitektur (FBA)
• Record (informatikk)
• Spor (diskstasjon)
• Voluminnhold (VTOC)

Merknader

Referanser

Videre lesning

• IBM Data Processing Division (februar 1974). Introduksjon til IBM Direct-Access Storage Devices and Organization Methods (PDF) (Tiende utgave). White Plains: Internasjonale forretningsmaskiner. OCLC   8063006 . GC20-1649-9 . Hentet 6. august 2014 .
• Development of 360/370 Architecture - A Plain Man's View PJ Gribbin, 10. februar 1989, kapittel 8–10.