Some thoughts and comments from my side. More may follow.....
>2) Lower level APIs (assembler or other HLLs)
> These are used to implement (1).
> Just about any program / job can call these or (1), and the first
> time it does it gets "dubbed" (8) with a z/OS Unix PID and can use
> the kernel (below)
By calling (2), programs are in fact calling the kernel. The kernel may
then recognize that the unit of work (TCB or SRB, "task" for short
hereafter)
has not yet been "authorized" to use its services. If so, the kernel
will
see if the task can become an authorized user, i.e. does the userid the
task is running under have UNIX credentials (uid/gid). If it has, then
the task is said as being "dubbed" (which involves creation of some
control blocks, an possibly more).
>3) The "Kernel" Address space (BPXOINIT?)
> Common services for (1), (2)
System address space "OMVS" is the kernel. "BPXOINIT" is the so
called init process. The former provides the services the latter
is the process with PID=1, becoming parent of all orphaned
processes.
>5) z/OS Unix "command" binaries
> Program binder objects that are stored in (or linked to by) a file
> in the zFS or HFS filesystem (4).
> Unix command binaries can be invoked by BPXBATCH/COZBATCH (see
> 10), or via fork()/spawn() APIs in (1) or (2), or more commonly by
> a shell (see 6).
You can sometimes read a distinction between "commands" and "utilities".
The former is then referring to the shell built in commands and the
latter is referring to the standalone binaries. Mostly this distinction
is not of importance but sometimes it may well be.
UNIX binaries (the binder objects) may also be stored in a PDSE and then
called via EXEC PGM= directly. If there is a corresponding entry in the
file system (external link or null file with sticky bit set), then these
binaries may also be called from a shell command line (or any of the
other
means you listed).
>6) The Unix "shell" program (/bin/sh, and example of (5)
> [snip]
> The shell can be run interactively, under TSO OMVS (see 10),
> [snip]
I'd prefer "The shell can be run interactively, via TSO OMVS..."
It sufficient that tasks run "under z/OS UNIX" :-)
>7) BPXAS initiator and its "forked" / (non locally) "spawned" address
> spaces.
> Typically associated with the z/OS Unix shell (6) and Unix
> "commands" (5), but not necessarily so.
Better: "BPXAS initiator and its "forked" / (non locally) "spawned"
*processes*.
BPXAS *is* the address space where forked()/spawned() processes run.
>8) A z/OS job that is "dubbed" (has issued a service (1) or (2) and
> has a Unix PID.
> This doesn't preclude it from accessing other resources, like
> traditional z/OS Datasets, etc.
You may add obtaining and freeing storage. There is no separate
storage management for z/OS UNIX, its all done by the single
VSM/RSM/ASM.
You may add workload management. There are no separate work unit queues,
"undubbed" TCBs/SRBs are on the same queues as "dubbed" ones. Etc, etc.
> - The "OMVS" TSO command is also contributory to the "Under z/OS
>UNIX" problem - it allows you to run a shell under TSO, but it is not
>integrated well with ISPF (IMO).
The OMVS TSO command processor had its rights in the nineties; it is
obsolete today. Its a PITA. People having a need to work with UNIx
shells interactively should use SSH/rlogin(/telnet) to login.
>So, when people say "Under z/OS UNIX" ( or "Under USS"), which of
>these do they mean?
No offence intended: They probably don't know :-)
--
Peter Hunkeler
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
