Re: Scheduled STCs running as instream procs?

[Dan D]

My test system is z/OS 2.2 but the message I indicated has been there for a
long time (before 1.13 ;-) )

I was thinking that your started job's JCL was ...

//WTOTEST JOB ...etc. ...
//STEPNAME EXEC WTOPROC

If that was your JCL then you'd have a message in JESYSMSG indicating where
WTOPROC was found.
If you just have straight inline JCL to run your started job it would come
from the IEFPDSI dataset wouldn't it?
If your IEFPDSI is a concatenation (is this possible?) then you'd have to
search them.

Sorry for not being more useful.
DanD


"Willy Jensen" wrote..
> Hm, interesting.
> 
> My started job starts with this:
> //WTOTEST  JOB (1),'WTOTEST',   
> // CLASS=A,REGION=32M   
> //* 
>   . . . etc etc 
> 
> SDSF shows the following files:
>  JESMSGLG 
>  JESJCL 
>  JESYSMSG 
>  SYSTSPRT TB  
> 
> No SYSMSGS.
> 
> The JESMSGS shows:
> IEF695I START WTOTEST  WITH JOBNAME WTOTEST  IS ASSIGNED TO USER START2  ,
GROUP SYS1  
> IEF236I ALLOC. FOR WTOTEST TB

> IEF237I 0AB4 ALLOCATED TO SYSEXEC

> IEF237I 0AB4 ALLOCATED TO

> IEF237I JES2 ALLOCATED TO SYSTSPRT

> IEF237I JES2 ALLOCATED TO SYSPRINT

> IEF237I JES2 ALLOCATED TO SYSTERM

> IEF237I DMY  ALLOCATED TO SYSTSIN

> Reply to continue

> IEF142I WTOTEST TB - STEP WAS EXECUTED - COND CODE 

> IEF285I   SYSX.JOBLIB.DATA KEPT

> IEF285I   VOL SER NOS= SYSXS1.

> IEF285I   SYSX.EXECKEPT

> IEF285I   VOL SER NOS= SYSXS1.

> IEF285I   START2.WTOTEST.STC08485.D101.?   SYSOUT

> IEF285I   START2.WTOTEST.STC08485.D102.?   SYSOUT

> IEF285I   START2.WTOTEST.STC08485.D103.?   SYSOUT

> IEF373I STEP/TB  /START 2016119.0923

> IEF032I STEP/TB  /STOP  2016119.0923

> CPU: 0 HR  00 MIN  00.25 SECSRB: 0 HR  00 MIN  00.00
SEC   
> VIRT:68K  SYS:   268K  EXT:  360K  SYS:10800K

> IEF375I  JOB/WTOTEST /START 2016119.0923

> IEF033I  JOB/WTOTEST /STOP  2016119.0923

> CPU: 0 HR  00 MIN  00.25 SECSRB: 0 HR  00 MIN  00.00
SEC   
> 
> This is from a z/OS 1.13. The proclib is in the IEFPDSI concatenation in
the MSTJCL.
> Perhaps we mean different things when we talk about started jobs?
> 
> Willy
 

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

Re: Scheduled STCs running as instream procs?

[Willy Jensen]

Hm, interesting.

My started job starts with this:
//WTOTEST  JOB (1),'WTOTEST',   
// CLASS=A,REGION=32M   
//* 
  . . . etc etc 

SDSF shows the following files:
 JESMSGLG 
 JESJCL 
 JESYSMSG 
 SYSTSPRT TB  

No SYSMSGS.

The JESMSGS shows:
IEF695I START WTOTEST  WITH JOBNAME WTOTEST  IS ASSIGNED TO USER START2  , 
GROUP SYS1  
IEF236I ALLOC. FOR WTOTEST TB   
   
IEF237I 0AB4 ALLOCATED TO SYSEXEC   
   
IEF237I 0AB4 ALLOCATED TO   
   
IEF237I JES2 ALLOCATED TO SYSTSPRT  
   
IEF237I JES2 ALLOCATED TO SYSPRINT  
   
IEF237I JES2 ALLOCATED TO SYSTERM   
   
IEF237I DMY  ALLOCATED TO SYSTSIN   
   
Reply to continue   
   
IEF142I WTOTEST TB - STEP WAS EXECUTED - COND CODE  
   
IEF285I   SYSX.JOBLIB.DATA KEPT 
   
IEF285I   VOL SER NOS= SYSXS1.  
   
IEF285I   SYSX.EXECKEPT 
   
IEF285I   VOL SER NOS= SYSXS1.  
   
IEF285I   START2.WTOTEST.STC08485.D101.?   SYSOUT   
   
IEF285I   START2.WTOTEST.STC08485.D102.?   SYSOUT   
   
IEF285I   START2.WTOTEST.STC08485.D103.?   SYSOUT   
   
IEF373I STEP/TB  /START 2016119.0923
   
IEF032I STEP/TB  /STOP  2016119.0923
   
CPU: 0 HR  00 MIN  00.25 SECSRB: 0 HR  00 MIN  00.00 SEC
   
VIRT:68K  SYS:   268K  EXT:  360K  SYS:10800K   
   
IEF375I  JOB/WTOTEST /START 2016119.0923
   
IEF033I  JOB/WTOTEST /STOP  2016119.0923
   
CPU: 0 HR  00 MIN  00.25 SECSRB: 0 HR  00 MIN  00.00 SEC
   

This is from a z/OS 1.13. The proclib is in the IEFPDSI concatenation in the 
MSTJCL.
Perhaps we mean different things when we talk about started jobs?

Willy

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

Re: Scheduled STCs running as instream procs?

[Lindy Mayfield]

That was the message I got.  And I forget exactly but $DPROCLIB gave me I think 
something like MSTJCL00, MSTJCL01, then some dataset names.

Cancelling a started task caused it to start right up again. 

So my problem was that normally I can work backwards on MVS to find the source 
code of the STC, but here I couldn't.  Some automation software was in control, 
and that instream message was new to me.  

If I was smarter I could have a) figured out where/how MSTJCLxx was allocated, 
b) figure out what automation software was used (probably Tivoli or one of 
those), or c) found somebody who knew. 

I honestly had to write a simple Rexx program to look at the control blocks to 
show what security program was being used, even though I was told and it was 
clear it was RACF.  I just saw too many messages starting ACF9, and hardly 
any ICH so perhaps they had major message suppression going on there that 
I'd never seen before. 

Br, 
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dan D
Sent: tiistaina 3. toukokuuta 2016 20.58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Scheduled STCs running as instream procs?


Willy,

If you look at the SYSMSGS of a started job you will still see ...
3 IEFC001I PROCEDURE procname WAS EXPANDED USING INSTREAM PROCEDURE
DEFINITION  

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

Re: Scheduled STCs running as instream procs?

[Dan D]

"Willy Jensen" wrote ...
> A started job will not tell you from where it came. On the other hand, it
will also not say instream.
> 
> Willy 
> 

Willy,

If you look at the SYSMSGS of a started job you will still see ...
3 IEFC001I PROCEDURE procname WAS EXPANDED USING INSTREAM PROCEDURE
DEFINITION  
Or 
2 IEFC001I PROCEDURE procname WAS EXPANDED USING SYSTEM LIBRARY dataset-name
I even got one to use a JCLLIB statement ...
4 IEFC001I PROCEDURE procname WAS EXPANDED USING PRIVATE LIBRARY
dataset-name

The trick is to programmatically READ sysmsgs.

DanD

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

Re: Scheduled STCs running as instream procs?

[Willy Jensen]

A started job will not tell you from where it came. On the other hand, it will 
also not say instream.

Willy

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

Re: Scheduled STCs running as instream procs?

[Dana Mitchell]

On Wed, 27 Apr 2016 22:16:49 +, Lindy Mayfield  
wrote:

>
> Today I saw something I've never seen before.  I wanted to know where a 
> started task was running from and normally the SDSF jes2 log shows which > 
> proclib it was loaded from.  But it said it was instream, and looking at the 
> SJ jcl it didn't look "normal."

Sounds like the startup JCL member contains a job card, that seems to suppress 
the normal IEFC001I message.  Makes it tough to find where JCL comes from!
It could also come from IEFJOBS DD concatenation in MSTJCLxx.

>
>$DPROCS showed something weird, I forget, but it was some proclib DD's, two or 
>3 of them, then the system proclibs by name (SYS1.PROCLIB, etc).
>

The JES2 subsystem has multiple proclib concatenations defined,  either static 
or dynamically via $ADD PROC commands.  The output of $DPROCS will show ' 
STATIC PROCLIB, '  if a concatenation was coded in the JES2 startup proc. 


HTH
Dana

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

Re: Scheduled STCs running as instream procs?

[Edward Finnell]

Yeah maybe Racf profiles for STARTED might give a clue.
 
 
In a message dated 4/27/2016 6:29:01 P.M. Central Daylight Time,  
stars...@mindspring.com writes:

Show us  the SJ output?  Anything else  relevant?



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

Re: Scheduled STCs running as instream procs?

[Lindy Mayfield]

Hello,

Yeah, after a very long day, then a long flight with time to think about it, 
then I thought to ask, and all I had in my head was sketchy.   I asked for the 
exact text about the instream from the JES2 sysout in SDSF by email so I can 
post it here later if it is helpful.

The STC is nothing more than a simple vendor daemon.  It doesn't do anything 
special. 

To be honest, out of frustration I threw together a quick Rexx program to look 
at the control block that says which security product was being used.  It was 
and is RACF.  But a search for ICH* in the system log made me think it was 
ACF/2 cause I saw a lot of messages starting something like ACF? (some letter 
or number) or similar.  But no, it's RACF used there.

Message suppression?  I expected ICH420I and the corresponding BPX messages.  
Probably the busiest system log I've seen in a long time, yet I couldn't find 
anything useful or that I expected.

Still, thanks Lizette as always for your help. :-)

Br,
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: torstaina 28. huhtikuuta 2016 1.28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Scheduled STCs running as instream procs?

Lindy,

These details are a little sketchy.  Could you add some more details?

What STC (Is it a vendor product or something else)?

Can you show us your display details that  you were looking at?

Show us the SJ output?  Anything else relevant?

Thanks

Lizette

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

Re: Scheduled STCs running as instream procs?

[Pinnacle]

On 4/27/2016 6:16 PM, Lindy Mayfield wrote:

No machines are as customizable as mainframes, especially ones that have been running for 
decades.  Sometimes things are hard to figure out, especially if the machine goes from 
the owner to outsourced or whatever, and all that, then people are "let go" and 
new people have to take over and try to understand.  Lots of times my job is to help with 
such transitions.

Today I saw something I've never seen before.  I wanted to know where a started task was 
running from and normally the SDSF jes2 log shows which proclib it was loaded from.  But 
it said it was instream, and looking at the SJ jcl it didn't look "normal."

$DPROCS showed something weird, I forget, but it was some proclib DD's, two or 
3 of them, then the system proclibs by name (SYS1.PROCLIB, etc).

When I stopped the STC, it started right back up again, which meant automation 
software was there.  It also meant that any proc of the same name in any of the 
SYS1. or similar proclibs wouldn't start before the ones that seems to be 
dynamically allocated in some way.

Anyone have any idea what software I'm dealing with?  I'll get around this by 
simply creating a new STC name with STDATA and new USER and putting it in one 
of the proclibs like SYS1.VDR.PROCLIB, but I'd like to understand if I can what 
I wasted a few hours trying to figure out and never did.  :)

Thanks and kind regards!
Lindy



Check MSTJCL00 if you can't find it in the JES2 PROCLIBs.

Regards,
Tom Conley

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

Re: Scheduled STCs running as instream procs?

[Lizette Koehler]

Lindy,

These details are a little sketchy.  Could you add some more details?

What STC (Is it a vendor product or something else)?

Can you show us your display details that  you were looking at?

Show us the SJ output?  Anything else relevant?

Thanks

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lindy Mayfield
> Sent: Wednesday, April 27, 2016 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Scheduled STCs running as instream procs?
> 
> No machines are as customizable as mainframes, especially ones that have been
> running for decades.  Sometimes things are hard to figure out, especially if
> the machine goes from the owner to outsourced or whatever, and all that, then
> people are "let go" and new people have to take over and try to understand.
> Lots of times my job is to help with such transitions.
> 
> Today I saw something I've never seen before.  I wanted to know where a
> started task was running from and normally the SDSF jes2 log shows which
> proclib it was loaded from.  But it said it was instream, and looking at the
> SJ jcl it didn't look "normal."
> 
> $DPROCS showed something weird, I forget, but it was some proclib DD's, two or
> 3 of them, then the system proclibs by name (SYS1.PROCLIB, etc).
> 
> When I stopped the STC, it started right back up again, which meant automation
> software was there.  It also meant that any proc of the same name in any of
> the SYS1. or similar proclibs wouldn't start before the ones that seems to be
> dynamically allocated in some way.
> 
> Anyone have any idea what software I'm dealing with?  I'll get around this by
> simply creating a new STC name with STDATA and new USER and putting it in one
> of the proclibs like SYS1.VDR.PROCLIB, but I'd like to understand if I can
> what I wasted a few hours trying to figure out and never did.  :)
> 
> Thanks and kind regards!
> Lindy
> 
> 

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

Re: Scheduled STCs running as instream procs?

[Steve Horein]

Curiosity piqued!
I would be interested in seeing what you're seeing.

On Wed, Apr 27, 2016 at 5:16 PM, Lindy Mayfield 
wrote:

> No machines are as customizable as mainframes, especially ones that have
> been running for decades.  Sometimes things are hard to figure out,
> especially if the machine goes from the owner to outsourced or whatever,
> and all that, then people are "let go" and new people have to take over and
> try to understand.  Lots of times my job is to help with such transitions.
>
> Today I saw something I've never seen before.  I wanted to know where a
> started task was running from and normally the SDSF jes2 log shows which
> proclib it was loaded from.  But it said it was instream, and looking at
> the SJ jcl it didn't look "normal."
>
> $DPROCS showed something weird, I forget, but it was some proclib DD's,
> two or 3 of them, then the system proclibs by name (SYS1.PROCLIB, etc).
>
> When I stopped the STC, it started right back up again, which meant
> automation software was there.  It also meant that any proc of the same
> name in any of the SYS1. or similar proclibs wouldn't start before the ones
> that seems to be dynamically allocated in some way.
>
> Anyone have any idea what software I'm dealing with?  I'll get around this
> by simply creating a new STC name with STDATA and new USER and putting it
> in one of the proclibs like SYS1.VDR.PROCLIB, but I'd like to understand if
> I can what I wasted a few hours trying to figure out and never did.  :)
>
> Thanks and kind regards!
> Lindy
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Scheduled STCs running as instream procs?

[Lindy Mayfield]

No machines are as customizable as mainframes, especially ones that have been 
running for decades.  Sometimes things are hard to figure out, especially if 
the machine goes from the owner to outsourced or whatever, and all that, then 
people are "let go" and new people have to take over and try to understand.  
Lots of times my job is to help with such transitions.

Today I saw something I've never seen before.  I wanted to know where a started 
task was running from and normally the SDSF jes2 log shows which proclib it was 
loaded from.  But it said it was instream, and looking at the SJ jcl it didn't 
look "normal."

$DPROCS showed something weird, I forget, but it was some proclib DD's, two or 
3 of them, then the system proclibs by name (SYS1.PROCLIB, etc).

When I stopped the STC, it started right back up again, which meant automation 
software was there.  It also meant that any proc of the same name in any of the 
SYS1. or similar proclibs wouldn't start before the ones that seems to be 
dynamically allocated in some way.

Anyone have any idea what software I'm dealing with?  I'll get around this by 
simply creating a new STC name with STDATA and new USER and putting it in one 
of the proclibs like SYS1.VDR.PROCLIB, but I'd like to understand if I can what 
I wasted a few hours trying to figure out and never did.  :)

Thanks and kind regards!
Lindy





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