>Ah, you're right. It's when I execute a command from the shell that the
digit is added to the end of the "jobname". I.e. the shell itself runs
under "USERID", but when I do a "sleep 60s", the sleep command runs under
"USERID1" (for example).
Every command that the shell fork()s will run in a se
>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
>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 char
>>How does cancelling the parent job affect its children? Might they continue
>>running?
>The same way it works on any unix: Child processed are terminated when the
>parent terminates.
The above statement is wrong. I mixed this up with special shell behaviour. The
shell terminates its childr
>How will this play with 8-character userids?
The same way as it already does and always did with 8-character jobname: The
jobname is not modified.
> There's no rule that JOBNAMEs must be prefixed with userid.
But fork() and non-local spawn() need a rule to build a jobname for the new
process
