Tilbage i uge 12 i 2016 skrev jeg et tip om at hente SMF data direkte fra en såkaldt logstream. Jeg bruger denne mulighed meget tit, og for et stykke tid siden ville jeg automatisere et SMF udtræk, så det blev foretaget hver time, men opdagede ved den lejlighed, at det ikke gik så stærkt, som jeg ellers synes, det gør. Og jeg kunne ikke forstå, at i outputtet stod der, at extract-programmet havde behandlet data for tre timer, når det nu kun var en time, jeg efterspurgte.

Så var der jo ikke andet at gøre end at søge på internettet for at finde ud af, hvad der kunne være galt. Det viste sig, at option SMARTENDPOINT var det, der drillede. Den fungerer sammen med en anden option kaldet SMARTEPOVER. Jeg har mere eller mindre opgivet at forstå, hvad denne option betyder, men default er 0200, som betyder 2 timer, og det er lige de to ekstra timer, extract-programmet skriver, at det behandler. Jeg har nu permanent tilføjet denne option, så mit extract step ser således ud (taget fra det tidligere tip):

//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
SMARTEPOVER(0000)
/*

SMARTEPOVER(0000) betyder, at der ikke scannes efter SMF records ud over intervallet angivet i START og END. Og det gør det i forvejen hurtige program endnu hurtigere. Jeg har endnu ikke stødt på en situation, hvor det at køre med SMARTEPOVER(0000) har givet nogen problemer med manglende data. Jeg har spekuleret på, om jeg bare skulle undlade SMARTENDPOINT og SMARTEPOVER, men jeg har endnu ikke haft tid til at undersøge det. Lad mig det vide, hvis du finder ud af noget!