As a responsible professional, you do not (and should not) "take it as it is".
Sometimes manual procedures are put in place as a stop-gap measure *after*
management has done a risk assessment. The situation may now have changed and
the RA is no longer valid, or whatever. Manual procedures should, generally, be
avoided if they can be automated. Not only are they boring for the people doing
them, but they are prone to errir. The 'human factor' is not auditable, logs are.
Les
Michel Beaulieu 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?
In one situation I have, operations staff are logging to service machines using LOGONBY
close the service, take a backup and then restart the service machine to
finally disconnect.
I am not trying to change the logic and the why things are done that way. I have to take it as it is.
I am just trying to see if I can add some automation first.
Later, behind the scene, I will be able to eliminate the need to log on to the service machines completely.
I hope this helps.
Michel Beaulieu
Montreal, Canada
|*|
Date: Fri, 17 Sep 2010 19:00:04 -0600
From: [email protected]
Subject: Re: Automated Logon (autofill userid and password) using TN3270 of
TCP/IP for VM or Logical Device
To: [email protected]
Yep - SVM's are VM 'daemons' .. DIRMAINT, RACFVM, and at least a VMUTIL or
some such guest that reacts to communication, be it reader, msg, smsg, ad
nauseum. It's the basis behind all VM system management tools and VM based
applications: a disconnected guest, running some version of CMS, which is
waiting for work which can come in many different forms. This also provides a
'queuing' ability to support requests from multiple users, which are handled
sequentially - first come, first served.
Actually logging into another guest as Michel suggests implies only one user
can run whatever application it is you're building. Maybe that's fine in this
case. But the typical way to support multi-user applications on z/VM, using
CMS guests, is to have a front end that runs in the end user guest -and that
communicates with one or more SVM's to either submit work and/or request
information. Very much like 'daemons' in the Unix world - at least, that's
how I think of them.
Anyway - if the real objective could be explained - I'm sure several of us
could suggest ways to not have to login to a USERB for your application to work.
Scott Rohling
On Fri, Sep 17, 2010 at 6:19 PM, Rich Greenberg <[email protected]> wrote:
On: Fri, Sep 17, 2010 at 04:34:15PM -0400,Rich Greenberg Wrote:
} The way this is often done is to have a program such as WAKEUP running
} in the service machine (SVM) which waits for an event (typically an SMSG
} from user"A" which requests something), does the requested work, returns
} the result (spool file or SMSG), and waits for the next request.
P.S. to above: If you ask 25 experienced, long time VM sysprogs,
if they have such a program, you will probably get 30 or so different
ones. Even IBM has one which ISTR is called VMUTIL EXEC and frequently
runs in a userid of the same name.
--
Rich Greenberg Sarasota, FL, USA richgr atsign panix.com + 1 941 378 2097
Eastern time. N6LRT I speak for myself & my dogs only. VM'er since CP-67
Canines: Val, Red, Shasta, Zero & Casey (At the bridge) Owner:Chinook-L
Canines: Red & Cinnar (Siberians) Retired at the beach Asst Owner:Sibernet-L
