Er det ikke lidt underligt, at når man skal allokere plads til et DB2-tablespace eller et DB2-index, så skal man angive allokeringen i KiloBytes (KB). For det første fylder en page 4KB, og de fleste (jeg gør i hvert fald) tænker i pages, når størrelsen af et tablespace skal beregnes. Så vidt jeg husker, så er de af IBM angivne beregningsformler også i pages. Og for det andet, så bliver de bagvedliggende VSAM-datasets allokeret i tracks eller cylinders. I det hele taget er det noget rod.

Jeg vil derfor komme med et par huskeregler, der giver en smule sammenhæng i denne rodebunke. Hvis man ønsker at få sit VSAM-dataset allokeret i tracks, så skal man angive sin PRIQTY og SECQTY i multipla af 48KB, altså f.eks. PRIQTY 480 SECQTY 240, som vil resultere i en primær allokering af VSAM-datasettet på 10 tracks primært og de sekundære extents vil være på 5 tracks. Hvis man vil allokere i cylinders, så skal man angive i multipla af 720KB, feks. PRIQTY 14400 SECQTY 2880, og det bliver til 20 cylinders primært og 4 cylinders sekundært. Hvis enten PRIQTY eller SECQTY ikke er i multipla af 720, så risikerer man, at allokeringen alligevel bliver i tracks.

Bemærk iøvrigt at alle ovenstående tal gælder for 3390-diske. For 3380-diske skal man regne i multipla af 40KB og 600KB. Med lidt hovedregning kan man nu let regne ud, hvor mange pages, der går på et track, som er det mindste stykke plads på disk, man kan allokere. For 3390-diske bliver det 12 pages og for 3380-diske bliver det 10 pages. Og for sådan nogle gamle MVS-nørder som mig, så kan jeg konstatere, at på en 3390-disk spilder DB2 6844 bytes (mere end en hel page) pr. track i forhold til en optimal udnyttelse. Jo, IBM sælger skam diske, men det betyder vist ikke så meget mere med RAID-systemer.