Tæl nøgledata - Count key data

Count key data ( CKD ) er et dataadgangsformat til direkte adgangslager (DASD), der blev indført i 1964 af IBM med dets IBM System / 360 og stadig emuleret på IBM mainframes. Det er et selvdefinerende format, hvor hver datapost er repræsenteret af et tælleområde, der identificerer posten og giver antallet af bytes i et valgfrit nøgleområde og et valgfrit datareal. Dette er i modsætning til enheder, der bruger fast sektorstørrelse eller et separat formatspor.

Tæll nøgledata (CKD) henviser også til sættet med kanalkommandoer (samlet Channel Command Words, CCWs), der genereres af en IBM-mainframe til udførelse af et DASD-undersystem, der anvender CKD-optagelsesformatet. Det oprindelige sæt CKD CCW'er, der blev introduceret i 1964, blev forbedret betydeligt og forbedret i 1990'erne.

CKD-sporformat

Blokdiagram over count key data sporformat, der anvendes på IBM mainframe computere, der begynder med S / 360-forsendelse i 1965

"Begyndelsen af ​​et spor signaleres, når indeksmarkøren (indekspunktet) detekteres. ... Markøren genkendes automatisk af en speciel sensorenhed." Efter indeksmarkøren er hjemmeadressen , som angiver placeringen af ​​dette spor på disken og indeholder anden kontrolinformation intern til kontrolenheden. Et hul med fast længde følger hjemmeadressen. Dernæst indeholder hvert spor en Record 0 (R0), track deskriptor record, som er "designet til at muliggøre, at hele indholdet af et spor kan flyttes til alternative spor, hvis en del af det primære spor bliver defekt." Efter R0 er datablokkene adskilt af huller.

Princippet med CKD-poster er, at da databloklængder kan variere, har hver blok et tilknyttet tællefelt, der identificerer blokken og angiver størrelsen på nøglen, hvis den bruges (brugerdefineret op til 255 byte), og størrelsen på dataområde, hvis det anvendes. Tællefeltet har identifikationen af ​​posten i cylinderhoved-record-format, nøglens længde og datalængden. Nøglen kan udelades eller bestå af en række tegn.

Hver CKD-post består af et tællefelt, et valgfrit nøglefelt og et valgfrit "bruger" -datafelt med fejlkorrektion / detektionsinformation, der er vedhæftet til hvert felt og huller, der adskiller hvert felt. På grund af hullerne og anden information er det registrerede rum større end det, der kræves for kun tælledata, nøgledata eller brugerdata. IBM leverer et "referencekort" til hver enhed, som kan bruges til at beregne antallet af blokke pr. Spor til forskellige blokstørrelser og til at optimere blokstørrelsen til enheden. Senere blev programmer skrevet til at udføre disse beregninger. Da blokke normalt ikke er opdelt mellem spor, kan specifikation af en forkert blokstørrelse spilde op til halvdelen af ​​hvert spor.

Oftest udelades nøglen, og optegnelsen placeres sekventielt eller ved direkte adressering af cylinderhoved-post. Hvis den er til stede, er nøglen typisk en kopi af de første n bytes i dataposten (for "ikke-blokerede" poster eller en kopi af den højeste nøgle i blokken til "blokerede" poster), men kan være alle data som vil blive brugt til at finde posten, normalt ved hjælp af søgetasten lig eller søgetasten høj eller lig CCW. Nøglen (og dermed posten) kan findes via hardwarekommandoer. Siden introduktionen af IBMs System / 360 i 1964 har næsten alle IBM store og mellemliggende system- DASD'er brugt optageformatet for tællernøgledata .

Fordelene ved optællingsformat for tællernøgle er:

• Registreringsstørrelsen kan nøjagtigt matches med applikationsblokstørrelsen
• CPU- og hukommelseskrav kan reduceres ved at udnytte kommandoer til søgetaster.
• IBM CKD-undersystemer oprindeligt drives synkront med systemkanalen og kan behandle information i hullerne mellem de forskellige felter og derved opnå højere ydelse ved at undgå den overflødige overførsel af information til værten. Både synkrone og asynkrone operationer understøttes i senere undersystemer.

Reducerede CPU- og hukommelsespriser og højere enheds- og interfacehastigheder har noget ophævet fordelene ved CKD, og ​​det bevares kun, fordi IBMs flagskibsoperativsystem z / OS ikke understøtter sektororienterede grænseflader.

Oprindeligt havde CKD-poster en en-til-en korrespondance med et fysisk spor af en DASD-enhed; over tid er pladerne imidlertid blevet mere og mere virtualiseret, således at der i moderne IBM-mainframes ikke længere er en direkte overensstemmelse mellem et CKD-record-id og et fysisk layout af et spor.

IBMs CKD DASD-undersystemer

IBM S / 360 & S / 370 Input / Output-operationer til CKD DASD, der viser kanal, lagerstyringsenhed og DASD-enhed

Programmering

Adgang til specifikke klasser af I / O-enheder via en IBM-mainframe er under kontrol af Channel Command Words (CCW'er), hvoraf nogle er generiske (f.eks. Ingen betjening), men mange af dem er specifikke for typen af ​​I / O-enhed ( Læs f.eks. bagud for et bånddrev). Gruppen af ​​CCW'er defineret af IBM til DASD falder i fem brede kategorier:

• Kontrol  - kontrol af DASD inklusive stien dertil
• Sense  - følelsesstatus for DASD inklusive stien dertil; nogle sansekommandoer påvirker status for controlleren og DASD på en måde, der er mere i overensstemmelse med en kontrolkommando, f.eks. RESERVE, RELEASE
• Skriv  - skriv information til controlleren eller DASD (som kan være bufret eller cachelagret i stien)
• Søg  - sammenlign oplysninger fra CPU'en med oplysninger gemt i DASD; kanalen fungerer i skrivetilstand, mens lagerenheden fungerer i læsetilstand.
• Læs  - læs oplysninger fra DASD (som kan være bufret eller cachelagret i stien)

CKD CCW'er er det specifikke sæt CCW'er, der bruges til at få adgang til CKD DASD-undersystemer. Dette er i modsætning til faste blokarkitektur (FBA) CCW'er, der bruges til at få adgang til FBA DASD-undersystemer.

CKD DASD adresseres som andre input / output-enheder; til System / 360 og System / 370 DASD adresseres direkte gennem kanaler og de tilknyttede kontrolenheder (SCU eller Storage Control Unit), der oprindeligt bruger tre hexadecimale cifre, en til kanal og to til styreenhed og enhed, der giver adressering til op til 16 kanaler, til op til 256 DASD-adgangsmekanismer / kanal og 4.096 DASD-adresser i alt. Moderne IBM-mainframes bruger fire hexidecimale cifre som et vilkårligt underkanalnummer inden for et kanalundersystemsundersæt, hvis definition inkluderer de faktiske kanaler, styreenheder og enhed, der giver adressering til op til 65.536 DASD pr. Kanalundersystemsundersæt. I praksis begrænsede fysiske og designmæssige begrænsninger af kanalen og controllerne det maksimale antal tilknyttede DASD, der kan fastgøres til et system, til et mindre beløb end det antal, der kunne adresseres.

Emballage

Oprindeligt var der en høj grad af overensstemmelse mellem den logiske opfattelse af DASD-adgang og den aktuelle hardware, som vist i illustrationen ovenfor. Tre cifrede etiketter blev typisk anbragt for at identificere adressen på kanal, kontrolenhed og enhed.

På low-end-systemer var kanalen og kontrolenheden ofte fysisk integreret, men forblev logisk adskilt. IBMs nye vedhæftningsstrategi, der begyndte med 3830 Model 2 i 1972, adskilt SCU'en fysisk i to fysiske enheder, en direktør og en controller, samtidig med at de blev logisk de samme. Controlleren håndterer CKD-sporformatering og er pakket med det første drev eller drev i en række drev og har et modelnummer med bogstavet "A" som præfiks, en "A-enhed" (eller "A-Box") som i 3350 Model A2 indeholdende en controller og to DASD'er. DASD uden en controller, det vil sige B-enheder, har et "B" præfiks i deres modelnummer.

CKD-undersystemer og direktører blev tilbudt af IBM og plug-kompatible konkurrenter indtil mindst 1996 (2301 til 3390 Model 9); i alt 22 unikke DASD tilbudt af IBM konfigureret i mindst 35 forskellige delsystemkonfigurationer . Plug-kompatibel tilbød mange af den samme DASD inklusive 4 CKD-undersystemer med unik DASD.

Indledende CKD-funktionssæt

Det oprindelige funktionssæt, der blev leveret af IBM med sin introduktion i 1964 af CKD - ​​sporformat og tilknyttede CCW'er inkluderet:.

• Defekt / alternativt spor  - gør det muligt for et alternativt spor at erstatte et defekt spor, der er gennemsigtigt med den anvendte adgangsmetode.
• Recordoverløb  - poster kan overstige den maksimale sporlængde for en DASD
• Multitrack-operationer  - specifikke CCW'er kan fortsætte til det næste sekventielle hoved
• Command chaining  - CCW'er kunne kædes sammen for at konstruere komplekse kanalprogrammer. Hullerne i et CKD-sporformat tilvejebragte tilstrækkelig tid mellem kommandoerne, så al kanal- og SCU-aktivitet, der er nødvendig for at udføre en kommando, kan udføres i afstanden mellem passende felter. Sådanne programmer kan søge i en stor mængde information, der er lagret på en DASD, når den vellykkede færdiggørelse kun returnerer de ønskede data og derved frigør CPU-ressourcer til anden aktivitet. Denne tilstand af synkron drift til mellemrummet blev senere forbedret med yderligere CCW'er, der muliggør en ikke- synkron driftstilstand .
• Kanalskift  - en SCU kan deles mellem kanaler - der blev oprindeligt leveret to kanalkoblinger, og den blev udvidet til op til otte kanaler i senere SCU'er. Kanalerne kan være på samme eller forskellige CPUS.

Et Scan-funktionssæt blev også leveret, men fortsatte ikke i fremtidige CKD-undersystemer ud over 2314.

Fyrre CCW'er implementerede funktionssættet:

Bemærkninger:

O = valgfri funktion

S = standardfunktion

MT = multitrack: når det understøttes, fortsætter CCW med at arbejde på de næste hoveder i rækkefølge til slutningen af ​​cylinderen

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

† = kode samme som MT Off undtagen som angivet

1. Filscanningsfunktion (9 CCW'er) kun tilgængelig på 2841 til 2302, 2311 og 2321; de var ikke tilgængelige på efterfølgende DASD-controllere til DASD senere end 2314.

2. Optælling er antallet af byte i søgeargumentet, inklusive maskebyte

De CCWS blev oprindeligt blev henrettet af to typer af SCU knyttet til systemets højhastigheds Selector Kanaler . Den 2820 SCU kontrollerede 2301 Drum mens 2841 SCU kontrollerede kombinationer af 2302 Disk Lager , 2311 Disk Drive, 2321 datacelle og / eller 7320 Drum Storage. IBM erstattede hurtigt 7320 med den hurtigere og større 2303.

Derefter blev funktionssættet implementeret i 2314-familien af ​​lagerkontroller og en integreret vedhæftning af System 370 Model 25 .

Det følgende eksempel på et kanalprogram læser en diskpost identificeret af et nøglefelt. Sporet, der indeholder posten og den ønskede værdi af nøglen, er kendt. SCU'en søger på sporet for at finde den ønskede post. I dette eksempel angiver <> at kanalprogrammet indeholder lagringsadressen for det angivne felt.

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

TIC (overførsel i kanal) får kanalprogrammet til at forgrene sig til SEARCH-kommandoen, indtil der registreres en post med en matchende nøgle (eller slutningen af ​​sporet). Når der findes en post med en matchende nøgle, vil SCU medtage Status Modifier i kanalstatus, hvilket får kanalen til at springe TIC CCW over; således forgrenes ikke kanalprogrammet, og kanalen udfører READ-kommandoen.

Bloker Multiplexer Channel Enhancements

Den blok multiplekser kanal blev introduceret første gang i 1971 på nogle høje ende System / 360-systemer sammen med 2835 Control Unit og tilhørende 2305 DASD, Denne kanal var så standard på IBM System / 370 og efterfølgende mainframes; når det står i kontrast til den tidligere Selector-kanal, tilbød den ydeevneforbedringer til enheder med høj hastighed såsom DASD, herunder:

Flere anmodninger

Tilladte flere kanalprogrammer at være samtidigt aktive i anlægget i modsætning til kun et med en vælgerkanal. Det faktiske antal leverede underkanaler afhænger af systemmodellen og dens konfiguration. Nogle gange beskrevet som frakoblet kommandokæde, kunne styreenheden afbryde forbindelsen på forskellige tidspunkter under et lænket sæt CCW'er, for eksempel frakobling til en Seek CCW, hvilket frigør kanalen til en anden underkanal.

Kommando forsøg igen

Kanalen og lagerkontrollen under visse betingelser kan fungere sammen for at få en CCW til at blive prøvet igen uden en I / O-afbrydelse. Denne procedure initieres af lagerkontrollen og bruges til at gendanne fra korrigerbare fejl.

Rotationspositionssensor

Rotationspositionssensing (RPS) blev implementeret med to nye CCW'er, SET SECTOR og LÆS SECTOR aktiverede kanalen til at forsinke kommandokæde, indtil disken roterede til en specificeret vinklet sporposition. RPS tillader kanalafbrydelse i det meste af rotationsforsinkelsesperioden og bidrager således til øget kanaludnyttelse. Kontrolenheden implementerer RPS ved at opdele hvert spor i lige vinklede segmenter.

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 eksempel overholder Record 0 IBM programmeringsstandarder. Med en blokmultiplexerkanal er kanalen fri i den tid, som DASD søger og igen, mens disken roterer til begyndelsen af ​​sporet. En vælgerkanal ville være optaget i hele dette prøveprograms varighed.

Fejl springer over

Fejlspring gør det muligt at skrive data før og efter en af ​​flere overfladefejl, der gør det muligt at bruge hele sporet bortset fra den del, der har defekten. Dette eliminerer også den tid, der tidligere var krævet for at søge et alternativt spor. Kun et begrænset antal defekter kunne springes over, så alternative spor forblev understøttet for de spor med overskydende mangler.

Fejlhoppning blev introduceret i 1974 med 3340 fastgjort via 3830 Model 2 Storage Control Unit eller integrerede vedhæftede filer på små systemer. Fejlspring var i det væsentlige kun en fabriksfunktion indtil 1981, da CCW'er til styring sammen med tilhørende forsyningsselskaber blev frigivet.

Dynamiske stier

Først introduceret med 3380 DASD på 3880 Storage Control Unit i 1981 blev funktionen inkluderet i de senere CKD DASD-undersystemer. Funktionen til valg af dynamisk sti styrer driften af ​​de to controllere, inklusive samtidig dataoverførsel over de to stier. Når det understøttes af operativsystemet, kan hver controller fungere som en alternativ sti, hvis den anden controller ikke er tilgængelig.

Tre ekstra kommandoer, Set Path Group ID, Sense Path Group ID og Suspend Multipath Reconnection, bruges til at understøtte vedhæftning af 3380-modellerne med to controllere i toppen af ​​en streng.

Kommandoen Set Path Group ID med funktionen DPS (Dynamic Path Selection) giver større fleksibilitet i operationer på reserverede enheder. Når en stygruppe for en enhed er oprettet, kan den få adgang til enhver sti, der er medlem af gruppen, som den er reserveret til. Derudover vil der på 370-XA-systemer, der indstiller flervejsmodusbit i funktionsstyringsbyte (byte 0) til en 1, blokmultipleksgenforbindelser forekomme på den første tilgængelige sti, som er medlem af gruppen, hvor kanalprogrammet var startet (uanset enhedens reservationstilstand).

Hvis den controller, der er angivet i I / O-adressen, er optaget eller deaktiveret, tillader det dynamiske stivalg en alternativ sti til enheden at blive etableret via en anden lagringsdirektør og den anden controller i modellen AA.

Ikke-synkron drift

Før 1981-introduktionen af ​​3880-direktøren blev der synkroniseret adgang til CKD-poster, alle aktiviteter krævede, at en CCW blev afsluttet, og den næste blev initieret i hullerne mellem CKD-felterne. Gapstørrelsen placerede begrænsninger på kabellængden, men sørgede for meget høj ydeevne, da komplekse kæder af CCW'er kunne udføres af delsystemet i realtid uden brug af CPU-hukommelse eller cyklusser.

Ikke-synkron operation leveret af det udvidede CKD ("ECKD") sæt CCW'er fjernede tidsbegrænsningen for mellemrum. De fem yderligere ECKD CCW'er er Define Extent, Find Record, Skriv opdateringsdata, Skriv opdateringsnøgle og data og skriv CKD næste spor.

I ikke-synkron drift synkroniseres ikke overførslen af ​​data mellem kanalen og lagerkontrollen med overførslen af ​​data mellem lagerstyringen og enheden. Kanalprogrammer kan udføres således, at kanal- og lagerkontrolaktiviteter, der kræves for at afslutte udførelsen af ​​en kommando og gå videre til den næste, ikke behøver at forekomme under mellemregistreringsgabet mellem to tilstødende felter. En mellemliggende buffer i lagerkontrollen tillader uafhængige operationer mellem kanalen og enheden. En stor fordel ved ECKD'er er langt længere kabler; afhængigt af anvendelsen kan det forbedre ydelsen.

ECKD CCW'er understøttes på alle efterfølgende CKD-undersystemer.

I dette eksempel læses ikke-synkront kanalprogram poster R1 og R2 fra spor X'0E 'i cylinder X'007F'. Begge poster har en nøgellængde på 8 og en datalængde 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 blev først introduceret i DASD CKD-undersystemer af Memorex (1978) og StorageTek (1981) blev derefter introduceret i slutningen af ​​1981 af IBM på 3880 Model 13 til modeller af 3380 med dynamisk pathing.

Cachen styres dynamisk af en algoritme; der er adgang til højaktivitetsdata fra cache med høj ydeevne, og der er adgang til data med lav aktivitet fra billigere DASD-lager. En stor hukommelse i Director, cachen, er opdelt i sporpladser, der gemmer data fra 3380 sporene. Et mindre område er et bibliotek, der indeholder poster, der gør det muligt at placere data i cachen.

Der blev også leveret cacher på efterfølgende indførte lagringskontroller.

Andre udvidelser

Over tid blev der implementeret et antal stykontrol-, diagnosticerings- og / eller fejlgendannelses-CCW'er på en eller flere lagringskontroller. For eksempel:

• Ubetinget reserve tillod frigivelse af en enhed, der er reserveret til en anden kanal, og reserveret enheden til den kanal, der udsteder kommandoen.
• Læs flere nøgledata kunne mere effektivt læse fulde spor, hvilket giver mere effektive sikkerhedskopier.

Beyond System / 370

Reducerede CPU- og hukommelsespriser og højere enheds- og interfacehastigheder har noget ophævet fordelene ved CKD, og ​​support fortsætter af IBM indtil denne dato, fordi dets flagskibsoperativsystem z / OS fortsat bruger CKD CCW'er til mange funktioner.

Oprindeligt havde CKD-poster en en-til-en korrespondance med et fysisk spor af en DASD-enhed; over tid er posterne imidlertid blevet mere og mere virtualiseret, således at der i en moderne IBM-mainframe ikke længere er en direkte korrespondance mellem et CKD-record-id og et fysisk layout af et spor. En IBM-mainframe konstruerer CKD-sporbilleder i hukommelsen og udfører ECKD- og CKD-kanalprogrammerne mod billedet. For at bygge bro mellem de oprindelige diske med fast blokstørrelse og ECKD / CKD-recordformatet med variabel længde kortlægges CKD-sporbillederne i hukommelsen på en række faste blokke, der er egnede til overførsel til og fra et FBA-diskundersystem.

Af de 83 CKD CCW'er, der er implementeret til System / 360 og System / 370 kanaler 56, emuleres på System / 390 og nyere systemer.

Se også

• Blokering (datalagring)
• Datasæt (IBM mainframe)
• Fixed-block-arkitektur (FBA)
• Record (datalogi)
• Spor (diskdrev)
• Volumenindholdsfortegnelse (VTOC)

Bemærkninger

Referencer

Yderligere læsning

• IBM databehandlingsafdeling (februar 1974). Introduktion til IBM Direct-Access Storage Devices and Organization Methods (PDF) (Tiende udgave). White Plains: Internationale forretningsmaskiner. OCLC   8063006 . GC20-1649-9 . Hentet 6. august 2014 .
• Udvikling af 360/370 arkitektur - et almindeligt menneskesyn PJ Gribbin, 10. februar 1989, kapitel 8-10.