De fleste af os ved, hvordan filstrukturen i Windows er opbygget. Men hvordan forholder det sig egentlig med vores viden om filstrukturen på mainframen. Det bekymrer vi os ikke ret meget om i det daglige arbejde, og det er vel egentlig også sådan det skal være. Jeg vil alligevel skrive lidt om opbygningen.
Et dataset befinder sig logisk på en volume. På hver volume er der et katalog over de datasets, der findes på den pågældende volume. Hvis man ikke ved, hvilken volume et dataset befinder sig på, må man prøve sig frem. Heldigvis fandt man hurtigt ud af, at det tog for lang tid at prøve sig frem og opfandt MVS kataloget. MVS kataloget er en oversigt over samtlige datasets på tværs af alle volumes og med en angivelse af, hvilken volume et dataset befinder sig på. Selve placeringen af datasettet på volumen står i volume kataloget.
MVS kataloget består af et såkaldt master katalog og nul til mange user kataloger. I princippet kan man klare sig alene med master kataloget, men det har mange ulemper. For det første bliver det meget stort, da alle datasetnavne skal registreres i det. For det andet så skal alle have update adgang til master kataloget, hvis alle skal kunne oprette datasets. For det tredie så er der kun en ad gangen, der kan få adgang til at lave update i master kataloget. Disse tre ting tilsammen gjorde, at IBM hurtigt fandt på at lave user kataloger. Ideen med et master katalog og et antal user kataloger er, at få så få updates på masterkataloget som muligt og at få nogle user kataloger, der ikke er alt for store.
Et user katalog er et katalog over en delmængde af alle datasetnavne med tilhørende volumes. Delmængden bestemmes af såkaldte alias entries i master kataloget. Et alias er typisk lig den første qualifier (hlq) i datasetnavnet, altså den del af datasetnavnet, der står før det første punktum. Når man definerer et alias i master kataloget fortæller man samtidig hvilket user katalog alias'et skal pege på.
Nu er vi klar til at benytte kataloget. Forestil dig nu, at MVS'en skal finde datasetnavn MY.BEAUTI.FUL.DATASET. Først scannes master kataloget efter et alias, der hedder MY. Hvis dette alias ikke findes, så antager MVS'en, at datasetnavnet er defineret i masterkataloget. Hvis det gør, så antager MVS'en, at datasetnavnet er defineret i det tilhørende user katalog. Hvis et nyt dataset skal oprettes er processen den samme for at finde ud af, om datasetnavnet skal defineres i master kataloget eller i user kataloget. Hvis du prøver at oprette et dataset med en hlq, der ikke er defineret et alias til i masterkataloget, så kan du få en RACF fejl, der fortæller dig, at du ikke har update adgang til master kataloget. For det meste vil du dog få en anden RACF fejl, der fortæller dig, at du ikke må DEFINE det pågældende dataset.
Nu kan du med en vis ret udbryde, "Hvad rager det mig". Kun hvis du er nysgerrig og vil forstå, hvad der foregår, så er ovenstående god viden. Endnu mere viden kan du få med kommandoen TSO LISTCAT. Som udgangspunkt har du read adgang til master kataloget, for ellers var du ikke i stand til at kunne finde dine egne datasetnavne. Du har som minimum også update adgang til det user katalog, hvor dine datasetnavne er defineret, ellers kunne du ikke oprette dem. Hvis du kan oprette datasets med en anden hlq end din user, så skal du også have update adgang til den eller de user kataloger, som disse datasetnavne skal defineret i. Det sker faktisk ind imellem, at nogen får en UPDATE afvisning på et user katalog, når de vil allokere et dataset, som de har ALTER rettighed til. Og du har næsten helt sikkert read adgang til samtlige user kataloger.
Du kan med andre ord se alle MVS katalog oplysninger. Men det hjælper ikke meget, når du ikke ved, hvad master kataloget eller user katalogerne hedder. Men det kan TSO LISTCAT hjælpe dig med. Før du kaster dig ud i brugen af TSO LISTCAT for at kigge på katalog oplysninger, så skal du udføre en TSO PROFILE NOPREFIX. Når du har fået styret din nysgerrighed, skal du udføre en TSO PROFILE PREFIX(<dit userid>). Hvis du glemmer den sidste TSO kommando, så vil du opleve mange sjove ting, når du vil arbejde med datasets under TSO. Navnet på master kataloget finder du nemmest med kommandoen:
Dette dataset skal pr. definition findes i master kataloget, ellers kan MVS ikke starte. Enhver LISTCAT ENT() kommando udskriver navnet på det katalog, som det pågældende datasetnavn er defineret i. Antag nu, at masterkataloget hedder SYSCAT.MASTER. Så vil kommandoen TSO LISTCAT CAT(SYSCAT.MASTER) UCAT udskrive navnene på samtlige user kataloger.
Hvis du arbejder på en installation med flere MVS'er samlet i et sysplex (det gør de fleste af os), så prøv at udføre TSO LISTCAT ENT(SYS1.LINKLIB) på de forskellige MVS'er. Du vil højst sandsynligt opdage, at master kataloget ikke hedder det samme på de forskellige MVS'er. Man opretter simpelthen et master katalog pr. MVS, men med samme indhold for at gøre adgangen til kataloget på de forskellige MVS'er så hurtig som mulig, men også for at have en kørende backup af master kataloget, hvis et af dem skulle komme til skade. Desværre sker der ofte det, at de forskellige master kataloger kommer ud af synkronisering og dermed ikke har samme indhold. Det kan have den mærkelige bivirkning, at nogle datasetnavne kan ses på en MVS, men ikke på en anden. Det gælder dog oftest datasetnavne defineret direkte i master kataloget, user katalogerne er næsten altid fælles.
Hvis du vil kende alle mulighederne med LISTCAT, så prøv en TSO HELP LISTCAT (eller endnu bedre en TSO TRAP HELP LISTCAT. Og her på falderebet lige et par eksempler:
Og en sidste advarsel. Hvis et katalog er stort (mange datasetnavne/alias'er), så vil en liste over dem allesammen tage rigtig lang tid at lave. Her er det godt at vide, at ATTN afbryder en TSO LISTCAT, men vil ikke virke, hvis du benytter TSO TRAP LISTCAT metoden. Du kan også udføre LISTCAT i TSO BATCH. Det giver langt færre problemer, og du kan søge i den udskrevne liste vha. SDSF eller SYSVIEW.