Det er blevet meget populært at starte indlæg på konferencer med en bemærkning om, at man ikke kan drages til ansvar for noget som helst af det, som man vil fortælle om. Dette gælder i høj grad for det emne, jeg nu vil behandle.
Wildcards på IBM mainframen er desværre ikke særligt entydige eller standardiserede på nogen måde. IBM benytter så vidt jeg kan gennemskue tre typer wildcards. Et wildcard, der gælder for et enkelt tegn, et wildcard, der gælder for nul til N tegn og et wildcard, der gælder for nul til flere qualifiers i et datasetnavn.
Følgende tabel viser hvilke wildcards, der benyttes i forskellige IBM mainframe produkter:
Produkt | Et tegn | 0 til N tegn | 0 til N DSN-qualifiers |
DB2/SQL LIKE | _ | % | n/a |
CICS CEMT/CEDA | + | * | n/a |
ISPF member navne | % | * | n/a |
ISPF dataset navne | % | * | ** |
HSM dataset navne | % | * | ** |
DFDSS dataset navne | % | * | ** |
CSI dataset navne | % | * | ** |
Som man kan se, så skiller DB2 sig ret meget ud. Hvad i alverden foregik der inde i hovedet på DB2-folkene hos IBM dengang. "Vi skal være anderledes for enhver pris". Hvorfor eksempelvis _ som wildcard for netop et tegn, når _ kan benyttes i DB2-navne. Det overgår simpelthen min forstand.
Der er heldigvis enighed om at benytte * som tegnet for nul til N tegn i en lang række andre produkter, og wildcard'et for netop et tegn syntes kun CICS-folkene skulle være anderledes. For at drille DB2-folkene har man valgt % som wildcard for netop et tegn. Er De forvirret? Tja, der er kun een ting at sige om dette makværk: lær ovenstående tabel udenad og lad være med at sætte spørgsmålstegn ved logikken.
Endnu en overraskelse i skemaet er nok, at ** i ISPF dataset navne dækker over nul til N qualifiers. De fleste vil nok hævde, at det gør * også, men * virker kun lidt a la **, når * står til sidst. * dækker i dette særtilfælde (som er meeget benyttet) over een til N qualifiers. En lille subtil detalje, da det absolut kun er i ISPF, at det forholder sig sådan. Jeg taler af bitter erfaring.