AW: Re: Where is format of Job ID documented?
>The real question behind the question was "if I am processing JOB ID's what >should I expect to see, and if I am presenting them to people who have never >heard of JES, what should they expect to see and what does it mean?" What does it mean to people that have not heard of JES? I guess such people the have not much knowledge about z/OS either. In that case, I'd say don't tell them anything about the jobid at all. Why? Because it is not telling you much anyway. If I run a shell command from TSO, it will normally be run in my TSO address space, tos the jobid associated with this command would be Tnnn. If I run the command in batch, it might be running in the batch job's AS or in a UNIX initiator AS (BPXAS), so the jobid would be Jnnn or Snnn, resp.. And if the same command is run from an STC, it mit be running in the STC's AS or again in a UNIX initiator AS, but the jobid will be Snnn in both cases. But even standard MVS services might be run as STC or as batch job. Some run CICS or IMS as STC, some as batch job. So, CICS/IMS will show up as either Snnn or Jnnn. -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>... OTOH: It might run under Master Scheduler not JES. Makes perfect sense to me. Firstly MOUNT is an MVS command, and secondly, one would not be (or have been) able to MOUNT a volume when JESx was down. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>Isn't the APPC initiator structure a complete clone of JES2? In other words, >it has its own rules and JES2 has no relation whatsoever with APPC jobs or its >jobids? As stated in another post I'm not too familir with APPC, but is there anything prohibiting an APPC program from dynamically allocating a SYSOUT file? If not, JESx must know about that address space and thus the Annn number would be managed by JESx the same way JESx is managing the number for TSU, STC, and batch jobs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>>I guess IBM's thinking is that we should just treat it as a magic cookie. It >>is guaranteed to be 8 EBCDIC characters that will identify a job or the like. >>End of story. >> >Used to be 7, IIRC. Don't you mix that up with TSO Userids which are restricted to 7 charactrers? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
> >Hmmm. If a batch job spawns (not forks) a subprocess with _BPX_SHAREAS=YES wouldn't that subprocess run under the parent's JobID; no BPXAS, no STC? Local child processes, started via local spawn(), or attach_exec(), or attach_execmvs(), are run in the same address space as the parent process. I.e. in the TSO, batch job initiator, APPC initiator or STC address space. (Don't know much about APPC programs, but I assume there is nothing prohibiting then to use UNIX services.) The same applies to the case when an non-UNIX program is being dubbed because it is using A UNIX service now, i.e. when it becomes a UNIX process. Jobname and jobid are address space level attributes, not task or process level. Non-local child processes, started via fork(), or non-local spawn(), *always* run in UNIX initiator address space, aka BPXAS. BPXAS was introduced with OS/390 V1.3 (I seem to remember). Before that, APPC initiators were used to provide a home for non-local child processes. -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
