Thank you every one very much for your valuable input.

From all I've read, the answer really wasn't very straightforward.  But the two 
experts SDSF and MXG call it Task Type, but not sure about IOF, I got bored 
looking for it.     

And in some of my own Rexx code I just found there were five types used: JOB, 
SUB, STC, TSU, OTH.  There wasn't a title (like Task Type) but I did assign 
them to variables starting ASCBxxxx.   (Personally with this particular work I 
only have JOB, STC, TSU).

John, the Unix stuff is so super cool like you said, but for me in this very 
particular case I am working on when I see a TSO user ID racking up CPU time as 
an STC, with my inside information I now know exactly what is going on.  They 
are spawned client/server sessions.

Regards,
Lindy

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of John McKown
Sent: Wednesday, November 19, 2014 3:08 PM
To: [email protected]
Subject: Re: What are STC, JOB and TSU?


I would probably say something like: "On z/OS there are four classifications of 
address spaces. Three of them are controlled by the Job Entry Subsystem (JES), 
and the type can be derived from the JES job id.
Those three types are J, S, and T; for JOB (batch work), STC (started task), 
and TSU (TSO users) respectively. The fourth type of address space is called a 
system address space. This type of address space runs outside of the control of 
the JES and so, normally, does do any SPOOL activity.
This type of address space can be started with an operator command by adding 
the SUB=MSTR parameter to the START. It can also be created programmatically 
using internal facilities such as the ASCRE system service. Since they run 
outside the control of JES, they do not normally have a JES job id. There are 
facilities whereby such an address space can register itself with JES, at which 
time it is given an STC job id."

I.e. substitute "address space" for "<blank>". I am fairly sure that when the 
CPU is not in a WAIT, that there is a value in the PSAAOLD which, IMO, makes 
that ASID the "current" ASID. Hum, is this true? The only thing I'm not sure of 
is a global SRB. Can PSAAOLD be zero while a global SRB is running? The STO 
control register has to have _something_ valid in it unless you are somehow 
running DAT OFF. Which is _extremely_ rare in z/OS.

Depending on the level of detail you want, you might not want to even mention 
the system address space in such detail. But you might want to mention it 
briefly because such will show up in SDSF, but without a JES assigned id.

I also don't know if you want to inject anything about the "weird and 
wonderful" way that z/OS UNIX works. I.e. a batch job, with a JOBnnnnn assigned 
to it, can be a UNIX process. But a child process, created with fork()/spawn(), 
runs as a separate STCnnnnn type address space (ignoring local spawn(), of 
course). But that may be too much information. I couldn't even make it clear to 
other experienced sysprogs (one of whom had been a vendor developer) very well. 
But that may be a personal (me) issue. <grin/>


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to