DIAG D4 influences what minidisks you can LINK (if you've got an ESM).  And,
if you are not connected yet to an SFS or DB2 server, a new connection will
be made as if you were the surrogate.  Finally, *new* spool files will get
the surrogate as creator.

It does not at all change the CP classes of the virtual machine issuing it.

DIAG D4 was created to make it possible for batch job run with the authority
of the job submitter.

With RACF you don't get some command like SUROGATE, but part of my RxServer
package is a DIAGD4 MODULE.

2010/9/20 Alan Ackerman <alan.acker...@bankofamerica.com>

> On Sat, 18 Sep 2010 10:00:33 -0400, Michel Beaulieu <
> beaulieumic...@live.ca> wrote:
>
> >
> >Hello,
> >
> >It is so interesting that people need to expand so much on "why" before
> discussing the "how".
> >
> >In Unix/Linux, we have the "su" command that let someone take another
> identification
> >for a while and when done, just exit and return to the normal userid.
> >Can we do something like that in z/VM?
>
> You have hit upon one of the fundamental differences between Unix and z/VM.
> Unix is process-
> oriented. z/VM is virtual machine oriented. In Unix you can spawn another
> process which (courtesy
> of su and other mechanisms) has greater privileges than the original
> process. In z/VM, virtual
> machines are hermetically sealed from one another, unless the system
> programmer does
> something to authorize breaking through, or unless you give a virtual
> machine non-class-G
> privileges. You cannot "spawn" another virtual machine. (You can AUTOLOG it
> though, given
> authorization, but you have in no way taken over its privileges.) This
> difference also explains why
> you can login to the same userid multiple times in Unix (different
> processes) but you cannot do
> that in z/VM (only one virtual machine). It also explains why there is no
> SSH server on z/VM, since
> that would require spawning other virtual machines.
>
> IBM built into CMS something called OpenEdition which is a Posix subset,
> but not a full Unix. In
> particular, it does not support the full Posix 'fork' command. IBM went
> ahead and upgraded z/OS
> to a fully Unix-compatible (but EBCDIC) Unix System Service, but did not do
> that for z/VM. It
> would have required significant changes to the CP component (the
> hypervisor) of z/VM. Whether or
> not that was a correct decision back then, I doubt it will ever happen now.
>
> There are many ways to do what you want to do in z/VM. WAKEUP is simply the
> simplest way to do
> it -- a built-in CMS command around which you can build an SVM. Unix does
> many things with
> daemons, so it should not be such a foreign idea to Unix folks. Similar
> things could be done
> directly in assembler -- from our viewpoint, it's easier to work in REXX.
>
> Another way is to use the logical device support facility built into z/VM.
> The logical device support
> facility allows a program to create a logical terminal, which can then log
> on, just like a real
> terminal, enter passwords, issue commands, etc. I would do that using the
> MPVM component of
> the PVM program product. But PVM is a non-free program product. There are
> free downloadable
> programs in the z/VM library that implement logical device support, and
> MIGHT allow automaton (I
> have not tried) or you could again write code in assembler. Of course, to
> do this, you would need
> to know the userid and password of the machine you want to logon to. And
> only one user could do
> it at a time.
>
> As someone else pointed out, there is diagnose D4. The manual says:
>
> DIAGNOSE code X'D4' is used by a master virtual machine when scheduling
> work on one of its
> worker virtual machines on behalf of an end user. The end user's user ID is
> considered to be the
> alternate user ID.
>
> I don't see how that really provides a way to increase the authority of a
> virtual machine. If you can
> do that, then, I'd think that would be a hole in z/VM's underlying security
> big enough to drive a
> truck through. (And therefore APARable.)
>
> Then there are APPC/VM and CPI Communications. These are rather more
> complex, but you could
> read up on them.
>
> Right, more WHY instead of HOW. But all that stuff I mentioned is
> documented, if you want to try
> it.
>
> Alan Ackerman
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to