Hvis du har beskæftiget dig bare en lille smule med SMF data, så ved du også, at SMF data typisk er tilgængelige om morgenen efter det døgn, som de er skabt i. årsagen til dette angives typisk som, at der er rigtig mange SMF data og det tager rigtig meget tid at behandle dem. Og ja, der er rigtig mange SMF data. Alle IBM produkter startende med selve operativsystemet skriver SMF data hele tiden fyldt med uanede mængder af information, hvoraf det meste kun er anvendeligt under helt særlige omstændigheder.

Til gengæld har det altid været muligt at behandle SMF data næsten lige så hurtigt, som de er blevet skabt. Det har dog krævet et setup, som de færreste installationer har haft lyst til at kaste sig ud i. For at hjælpe på situationen har IBM opfundet noget, der kaldes for logstreams. SMF kan sættes op til at anvende logstreams og så bliver det faktisk muligt på en nem måde at få fat på SMF data nærmest i samme sekund de bliver skrevet.

For at du kan få fat på SMF data hurtigst muligt kræver det altså, at din installation har sat SMF op til at bruge logstreams. Hvis du må udstede operatør-kommandoer, så gå i SDSF og fyr kommandoen /D SMF af. Hvis outputtet indeholder noget med IFASMF.etEllerAndet, så bruger SMF logstreams. Næste trin er så at undersøge hvilke SMF logstreams, der er sat op, og hvad de indeholder, så du kan få fat i den logstream, der indeholder de SMF data, du er interesseret i. Dette er beskrevet i et parmlib member kaldet SMFPRM??, så næste skridt er at finde ud af hvilket parmlib, du skal kigge i. Kommandoen /D PARMLIB udskriver concateneringen af parmlibs, og så er det ellers at gå på jagt efter det første SMFPRM?? member. ?? afhænger af, hvordan der er blevet IPL'et, og her gætter jeg mig frem. Et SMFPRM member ser typisk således ud, hvis det er sat op til at køre med logstreams:

ACTIVE
INTVAL(15)
MEMLIMIT(&MEMLIMIT.)
SYNCVAL(59)
RECORDING(LOGSTREAM)
DEFAULTLSNAME(IFASMF.SMFDATA)
       LSNAME(IFASMF.CICSDATA,TYPE(110))
       LSNAME(IFASMF.DB2DATA,TYPE(100:102))
       LSNAME(IFASMF.RACFDATA,TYPE(080:083))

Det interessante er parametrene DEFAULTLSNAME og LSNAME. Navnet i DEFAULTLSNAME er den logstream, som en SMF record havner i, hvis den ikke havner i en af de logstreams, som er angivet med LSNAME. Efter navnet på en logstream i parameteren LSNAME står der, hvilke typer SMF-records, der havner i den pågældende logstream. Så nu kan du altså bestemme hvilken logstream, du skal bruge for at få fat i de SMF data, du er interesseret i. Så skal du bare have dem trukke ud. Det gør du med følgende step:

//SMFEXTRC EXEC PGM=IFASMFDL
//DUMPDATA DD DISP=(NEW,CATLG,DELETE),SPACE=(TRK,(999,999),RLSE),
//         UNIT=(,59),LRECL=32760,RECFM=VBS,
//         DSN=MY.SMF.EXTRACT
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
LSNAME(IFASMF.DB2DATA,OPTIONS(DUMP))
OUTDD(DUMPDATA,TYPE(101))
SID(MVSA)
START(0800)
END(0815)
RELATIVEDATE(BYDAY,0,1)
SMARTENDPOINT
/*

Dette step udtrækker SMF-records 101 fra logstream IFASMF.DB2DATA på MVS-systemet MVSA, som er blevet dannet mellem kl. 8.00 og 8.15 samme dag som steppet eksekveres. I princippet kan dette step allerede køres kl. 8.16, men det er ikke sikkert, at de SMF data, du er interesseret i, er landet i logstream'en. Dels kan SMF holde på data og dels er det ikke sikkert, at data er skrevet til SMF. For eksempel udskriver DB2 først type 101 records, når en transaktion eller et job er færdig med at eksekvere. I ovenstående eksempel udskrives SMF data i datasettet MY.SMF.EXTRACT. Dette dataset skal desværre allokeres som et spanned dataset med den angivne LRECL. Derfor kan datasettet ikke behandles med ISPF EDIT/VIEW (men godt med BROWSE), hvilket er ret irriterende. Men det er fantastisk at kunne få fat i SMF records stort set lige efter, at de blevet dannet. Det har jeg allerede haft glæde af ved flere lejligheder.