Thanks much, Barbara. Follow-ups in-line.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Barbara Nitz
Sent: Wednesday, January 04, 2012 9:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calling all experts on SMFPRMxx SUBSYS

Charles,

> If *I* understand you right, then you're confusing SUBSYS as indicated in
SMFPRM and a subsystem defined to the SSI.
> The SMF SUBSYS types *I* am aware of are JESx, STC, TSO, OMVS, ASCH.
That's it. 

So, is it true that for SMFPRMxx SUBSYS(xxx,(... the only useful "xxx" are
the five or six types listed above? I say "useful" rather than "valid"
because I don't mean that SMF would necessarily generate an error for
SUBSYS(FOO( -- it might, I just don't care at this moment -- but it would
not be meaningful to specify. You might have an SSI subsystem named FOO, but
SMFPRMxx SUBSYS(FOO( would either be rejected or else would have no effect
on it or SMF. Right?

> TYPE30 can be written for any SUBSYS type. As can TYPE80. 100, 101, 102,
119:  
> If an application that is TYPE OMVS  ... has calls into DB2, then they
would get written for TYPE OMVS 
> if that address space was started using the USS interfaces for creating an
address space.

... and any SUBSYS(OMVS( statements would control whether they were written
and whether IEFU8x was called for those records, right?

> When in doubt, have your customer have one SYS statement that only
specifies the types that are to be written ...

In an ideal world, yes. In the real world, we are one of those $%%#$@$
vendors and we are dealing with some overworked, undertrained, junior
sysprog, and telling him or her "make big changes to your SMFPRMxx" sets off
little alarm bells that go "this vendor's product is not worth getting fired
over." The more minimal a change we can *suggest* the better our chances of
success. This whole thing would be an easy problem if I could control the
SMFPRMxx. In many cases, I am trying to sort out a bunch of possible causes
of a problem, and so I need to know what their SMFPRMxx is "saying" (no
matter how "illogically" it may be coded) so that I don't go chasing after
the wrong problem. Hence these kind of obscure questions.

> HTH

Very much. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Reply via email to