Access to SMF files

[belenmh]

Hello everybody,

I'm very new in here, so I don't feel like spamming you. I've been reading the FAQs and checking out the word 'SMF' for more info, but... just in case, I want to be sure about this, because the other day my user was revoked because I was looking for those files, maybe in a wrong way or something...

I need to access SMF files because I want to test some JCLs that reach that kind of info and process it to get some statistics of my executions. Is it possible? I mean, am I allowed to access those libraries where SMF files are? Don't want to believe I know more than I actually do

I've read those datasets are in LOG.SMF.*.? Is that right?

Thanks!

[prino]

I need to access SMF files because I want to test some JCLs that reach that kind of info and process it to get some statistics of my executions. Is it possible? I mean, am I allowed to access those libraries where SMF files are? Don't want to believe I know more than I actually do

Not ever having accessed SMS records, but knowing that they record rather a lot about what's happening in the system, I'm not sure if the other admins would be very happy about giving you access to this data...

Can't you get the info you want in any other way?

[belenmh]

Heey! Thanks so much for replying

The point is that I want to access to SMF files (I do not care about the contained information actually) to get to build the proper JCLs under my own user datasets that proccess those files and get to know about the different type of registers and sub-types. Those are the things I want to do here: try that, process SMF files to get statistics about whatever (depending on the type of registers).

That's why I was asking... cos I know the type of information in them might be confidential. But this is, as I said, just for learning about SMF files and their use...

Please, can you give me any solution for that then?

[steve-myers]

As far as I know, access to SMF data is not restricted. However, you will find that analyzing the data requires fairly advanced programming skills. Most of the data is described in z/OS V1R6.0 MVS System Management Facilities (SMF).

By the by, if the admins have revoked your ID, how do you propose to access this data?

[belenmh]

Thank you very much for the response, that's what I was waiting for; getting to know if the data was restricted somehow because I did not want to enter somewhere you may dislike.

Well, that's another point. I was about to ask for another ID since I knew exactly why my user was revoked. I did it by mistake, by an error. Don't know how I ended up in DITTO when I didn't want. It took me half of a second to realize, but it was already late.

I'm very respectful, really.

Thank you again,

[steve-myers]

... I did it by mistake, by an error. Don't know how I ended up in DITTO when I didn't want. It took me half of a second to realize, but it was already late. ...

I have to agree with you about DITTO. It seems to me a large percentage of the users that get revoked have wondered into DITTO by mistake and then apparently attempted to damage or delete a user catalog. Still, in a couple of months I'll have been on the system for 3 years and never managed to get into DITTO, either by intent or error!

[steve-myers]

I presume you're the person attempting to copy one of the LOG.SMF data sets using the IFASMFDP utility. As you have discovered they are quite large. I would make these suggestions.

• Delete the failed copy data sets. I would suggest using DISP=(NEW,CATLG,DELETE) on your OUTDD1 DD statement.
• I do not understand why you specify a concatenation of the LOG.SMF.G0011V00 and LOG.SMF.G0011V00 in your INDD1 data set.
• Use relative generations rather than absolute generations.
• Just read the LOG.SMF data sets directly. The LOG.SMF data sets are just ordinary sequential data sets, and are no more difficult to read than the data sets you are creating with IFASMFDP.
• If you insist on copying them - which is OK - just select the records you want to use rather than all of the records. An alternate would be to select the dates you want to check.
• I have found from bitter experience the IFASMFDP date and time selection criteria do not work the way a reasonable person would expect. If you are interested I can send you a copy program that is a little faster than IFASMFDP, has date and time selection ranges that work the way a reasonable person would expect AND uses dates in the form yyyy/mm/dd rather than the rather stupid "Julian" dates IFASMFDP wants. This program was never intended for general use, but it seems to be reasonably reliable. I've been running it twice a day for several weeks.

[prino]

Analyzing SMF records requires understanding the structure and encoding of SMF records. This is by no means a task to be undertaken with the notion that you will absorb 800 + pages of SMF documentation in a manner that will add to your understanding of your job metrics. If you are indeed serious about looking at YOUR job execution metrics JES has dutifully reported the metrics at Job completion. These metrics are the basis of SMF data for the zOS batch sub-system. Have you studied the JES generated job statistics. What other metric could you possibly be interested in. I suggest that you download the JES SYSOUT's for your jobs and analyze those data. I believe SIO's can also be extracted from the simple JES reporting. Here is a representative job:

Code: Select all

JOBNAME  STEPNAME PROCSTEP    RC   EXCP    CPU    SRB  CLOCK   SERV  PG   PAGE   SWAP    VIO SWAPS STEPNO
ABC1XF9P TEST          DMAPST       00   8178     .00    .00    .07       18530   0      0      0      0     0     3         1