If you have been working with SMF data you know they are typically available early in the morning the day after they were created. Why it is this way is explained with the large amounts of SMF data produced and the time it takes to process them. And yes, there is a huge amount of SMF data. All IBM products starting with the operating system itself write SMF data all the time containing endless amounts of information and most of it is only usable under special circumstances.

On the other hand it has always been possible to process SMF data almost just as fast as they are created. It has required a setup that most installations has not seen themselves fit to create. To help relief the situation IBM has invented something called logstreams. Collection of SMF data can be configured to use logstreams which enables an easy way of accessing SMF data almost as soon as they are written.

For you to be able to pick up on SMF data as soon as possible your installation must be set up to use logstreams for SMF data. If you are allowed to execute operator commands then start SDSF and execute the command /D SMF. If the output contains something like IFASMF.something then SMF uses logstreams. Next step is to find out which logstreams are created and what they contain so you can access the logstream containing the SMF data you are interested in. This is described in a parmlib member called SMFPRM??. So you need to find out which parmlib you find the member in. The command /D PARMLIB displays the parmlib concatenation and then you just go hunting for the first SMFPRM?? member. The value of ?? depends on how the IPL was performed and here I take a guess. A SMFPRM member typically looks like this if SMF is set up to use 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))

The interesting part is the parameters DEFAULTLSNAME and LSNAME. The name in DEFAULTLSNAME is the logstream where a SMF record ends if it does not end in one of the logstreams specified by the LSNAME parameter. After the name of a logstream in LSNAME it is specified which types of SMF records ends in the corresponding logstream. So now you can see which logstream to use in order to extract the SMF data you are interested in. Then you just need to extract them if you are authorised:

//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
/*

This step extracts type 101 SMF records from the logstream IFASMF.DB2DATA on MVS system MVSA created between 8:00 and 8:15 the same day as the step is executed. You can run this step at 8:16 but it is not given that the SMF data you are interested in has been placed in the logstream. SMF may keep data in storage and the data may not be written to SMF. DB2 for instance when processing type 101 records delays writing them to SMF until a transaction or a jobstep terminates.

In the above example the extracted SMF records are written to dataset MY.SMF.EXTRACT. Unfortunately this dataset must be allocated as a spanned dataset with the specified LRECL. This prevents the dataset from being processed by ISPF EDIT/VIEW (but BROWSE works) which is pretty annoying. On the other hand it is fantastic to get hands on SMF records almost as soon as they have been created. I have already enjoyed this luxury several times.