This answer 'clarifies' the situation? Kees.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 19 November, 2014 14:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What are STC, JOB and TSU? On Wed, Nov 19, 2014 at 6:23 AM, Lindy Mayfield <lindy.mayfi...@sas.com> wrote: > Hi group, > > I'm having a bit of a problem identifying what classification those > names are. > > I know what started tasks and TSO users and batch jobs are, but if I > were to say: > > "On MVS there are three <blank> (or three types of <blank>) which can > be derived from the JES job ID. J or JOB means batch, S or STC means > started task and T or TSU means a TSO user." > 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/> > (My best guess was 'job type') > > Are there more than these three? I'm simply writing some high-level > documentation, and I've already used up my quota of writing "thingy" > when I don't know what it is. MVS has a lot of thingies. > > Thanks for your help. > Lindy > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
