Re: Two running job program name discovery questions

[Dan]

I have a very old SPL: SMF manual.  For SMF30PGM it shows the source is 
SCTPGMNM.
I wish they still showed where the data came from in the doc as well as the 
MACRO itself.

Dan

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

Re: Two running job program name discovery questions

[Charles Mills]

Thanks,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, September 13, 2016 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two running job program name discovery questions

SMF30PGM: the source is not a programming interface field. It is not the
RB's CDE's CDNAME field.

SMF30_Highest_Task_CPU_Program: The CDNAME field from the CDE from the
oldest RB for the particular task if there is a CDE for that RB. If there is
no CDE for that RB, then 8 question-marks or blanks; the code suggests that
the case of "blanks" should never happen, but is there "just in case".

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

Re: Two running job program name discovery questions

[Peter Relson]

SMF30PGM: the source is not a programming interface field. It is not the 
RB's CDE's CDNAME field.

SMF30_Highest_Task_CPU_Program: The CDNAME field from the CDE from the 
oldest RB for the particular task if there is a CDE for that RB. If there 
is no CDE for that RB, then 8 question-marks or blanks; the code suggests 
that the case of "blanks" should never happen, but is there "just in 
case".

Peter Relson
z/OS Core Technology Design


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

Re: Two running job program name discovery questions

[John McKown]

On Mon, Sep 12, 2016 at 3:38 PM, Walt Farrell 
wrote:

> On Mon, 12 Sep 2016 11:50:35 -0700, Charles Mills 
> wrote:
>
> >@Walt, thanks, that helps.
> >
> >I got it. I understand the limitations.
> >
> >I wonder where SMF gets SMF30PGM from.
>
> Good point. Perhaps JSCBPGMN (once you've found the right JSCB, of course).
>

​Shear guess on my part, but I'd bet that the initiator gets that
information from the SWA control blocks​ when it writes the SMF record. But
that depends on which of the subtypes of the type 30 you're speaking of.
The one I'm thinking of is the one written at step termination (subtype 4).



>
> --
> Walt
>
>


-- 
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: Two running job program name discovery questions

[Walt Farrell]

On Mon, 12 Sep 2016 11:50:35 -0700, Charles Mills  wrote:

>@Walt, thanks, that helps. 
>
>I got it. I understand the limitations. 
>
>I wonder where SMF gets SMF30PGM from.

Good point. Perhaps JSCBPGMN (once you've found the right JSCB, of course).

-- 
Walt

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

Re: Two running job program name discovery questions

[Charles Mills]

@Walt, thanks, that helps. 

I got it. I understand the limitations. 

I wonder where SMF gets SMF30PGM from. They don't seem to have any qualms about 
its reliability: "Program name (taken from PGM= parameter on EXEC card). If a 
backward reference was used, this field contains PGM=*.DD." It's not just that 
they grab it at the moment it happens because it is populated (apparently) for 
all SMF 30's including end-of-job. (What the heck is the jobstep program name 
for the end of a multi-step job?!) 

> a user might have a totally unrelated X in one of his libraries

Certainly any programmer with the most basic of privileges could create a 
"private" program named anything he wished.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Monday, September 12, 2016 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two running job program name discovery questions

On Mon, 12 Sep 2016 09:25:02 -0700, Charles Mills <charl...@mcn.org> wrote:

>@Walt, I would call the exact, full answer to that question 
>proprietary, but a hopefully-adequate answer is "report it as-is to 
>humans in >human-readable form." In other words, I don't intend to base 
>additional machine processing on it -- such as attempting to find it in the 
>load library chain. So I'm pretty flexible -- I would not have a problem with 
>a solution that was "arguable" for some scenarios. I am prepared to say "this 
>is the answer we give to this question -- if you don't like it, well, sorry."

That helps; thanks. 

For the non-UNIX case you could consider using your current TCB's pointer to 
TCBJSTCB (jobstep task TCB) then follow the RB chain to the end (first RB), 
find its CDE, and get the module name from that CDE.

Several failure scenarios I can think of off-hand:
(1) An authorized program is running in your address space, and it attached 
multiple jobstep TCBs. Workaround: There's a field that identifies the 
cross-memory owning TCB,  which should be the first one the initiator attached, 
and would give you a better answer. But I don't remember the name of the field.

(2) The program the initiator attached might have done an XCTL and transferred 
control to another module, and you would get the name of that second module. 
There's no workaround using this set of control blocks, as far as I know. You 
might need something different, perhaps using SWA.

(3) This doesn't tell you anything about where the program came from, so when 
you report that it was program X they'll have no idea which copy of X it was. 
And while the installation might know that they've covered the possibility of 
multiple copies of X within their libraries, a user might have a totally 
unrelated X in one of his libraries that the installation won't know about.

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

Re: Two running job program name discovery questions

[Walt Farrell]

On Mon, 12 Sep 2016 09:25:02 -0700, Charles Mills  wrote:

>@Walt, I would call the exact, full answer to that question proprietary, but a 
>hopefully-adequate answer is "report it as-is to humans in >human-readable 
>form." In other words, I don't intend to base additional machine processing on 
>it -- such as attempting to find it in the 
>load library chain. So I'm pretty flexible -- I would not have a problem with 
>a solution that was "arguable" for some scenarios. I am 
>prepared to say "this is the answer we give to this question -- if you don't 
>like it, well, sorry."

That helps; thanks. 

For the non-UNIX case you could consider using your current TCB's pointer to 
TCBJSTCB (jobstep task TCB) then follow the RB chain to the end (first RB), 
find its CDE, and get the module name from that CDE.

Several failure scenarios I can think of off-hand:
(1) An authorized program is running in your address space, and it attached 
multiple jobstep TCBs. Workaround: There's a field that identifies the 
cross-memory owning TCB,  which should be the first one the initiator attached, 
and would give you a better answer. But I don't remember the name of the field.

(2) The program the initiator attached might have done an XCTL and transferred 
control to another module, and you would get the name of that second module. 
There's no workaround using this set of control blocks, as far as I know. You 
might need something different, perhaps using SWA.

(3) This doesn't tell you anything about where the program came from, so when 
you report that it was program X they'll have no idea which copy of X it was. 
And while the installation might know that they've covered the possibility of 
multiple copies of X within their libraries, a user might have a totally 
unrelated X in one of his libraries that the installation won't know about.


I don't remember enough about the control block chasing for the UNIX case.

-- 
Walt

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

Re: Two running job program name discovery questions

[Charles Mills]

@Walt, I would call the exact, full answer to that question proprietary, but a 
hopefully-adequate answer is "report it as-is to humans in human-readable 
form." In other words, I don't intend to base additional machine processing on 
it -- such as attempting to find it in the load library chain. So I'm pretty 
flexible -- I would not have a problem with a solution that was "arguable" for 
some scenarios. I am prepared to say "this is the answer we give to this 
question -- if you don't like it, well, sorry."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Monday, September 12, 2016 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Two running job program name discovery questions

On Mon, 12 Sep 2016 07:24:13 -0700, Charles Mills <charl...@mcn.org> wrote:

>1. Sorry -- I seem to have the feeling this has been covered before but 
>I was not able to find the discussion. How -- through control block 
>chasing or macros -- can a running program discover the name of the 
>jobstep program, the name specified in EXEC PGM= or a USS shell equivalent?
>

I'm curious what you intend to do with the name once you know it. I suspect 
there are a number of "solutions" to your question that won't be satisfactory 
for some usage scenarios.

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

Re: Two running job program name discovery questions

[Walt Farrell]

On Mon, 12 Sep 2016 07:24:13 -0700, Charles Mills  wrote:

>1. Sorry -- I seem to have the feeling this has been covered before but I
>was not able to find the discussion. How -- through control block chasing or
>macros -- can a running program discover the name of the jobstep program,
>the name specified in EXEC PGM= or a USS shell equivalent?
>

I'm curious what you intend to do with the name once you know it. I suspect 
there are a number of "solutions" to your question that won't be satisfactory 
for some usage scenarios.

-- 
Walt

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