On Wed, Jan 10, 2018 at 3:24 PM, Paul Gilmartin < 0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 10 Jan 2018 21:05:15 +0000, Barkow, Eileen wrote: > > >Thanks again John. I will try it out. > > > >The problem is when a program is started from OMVS under a USERID and > runs under a different name, which makes it > >difficult for someone to cancel the job or issue modify commands against > it. > >The system keeps appending numerical values to the USERID and you have to > do a DA userid* command to find what it is. > >I just want to be able to display the actual JOBNAME to the console. > > > Ouch! Of course, fork() creates a new job (sort of) with a different job > name (really). > Unless the jobname is already 8 characters. In that case, then fork()'d address space has the same name as the parent. > > How will this play with 8-character userids? > Userids have nothing to do with job names, in general. If a user logs into a UNIX shell, the UNIX process runs in a new STC whose name is based on the USERID plus 1 character (sort of "random"). I am _guessing_ that with an 8 character RACF id, the UNIX process runs in an STC with the 8 character RACF ID. > > There's no rule that JOBNAMEs must be prefixed with userid. > Very true. > > How does cancelling the parent job affect its children? Might they > continue running? > Just like with any other UNIX. The fork()'d address space (child) continues to run independently of the parent's life. If the parent terminates, then the BPXOINIT address space becomes the child's new UNIX parent. Just like in any other UNIX, the child is "inherited" by PID==1. > > -- gil > > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
