I played around with LOGONBY and FTP and found something a little strange.
Context: z/VM 5.4 with RACF installed, CP deferring to RACF for almost
everything.
RACF profile SURROGAT LOGONBY.TESTUSER exists, with the ACL not including
TESTUSER itself.
CP logon allows users in the ACL to log
On Wednesday, 06/10/2009 at 10:54 EDT, Mark Bodenstein m...@cornell.edu
wrote:
RACF profile SURROGAT LOGONBY.TESTUSER exists, with the ACL not
including
TESTUSER itself.
...
FTP logon allows users in the ACL to use testuser.by.surrogate to log
on
to TESTUSER as expected, but DOES allow
these servers
actually get autologged, so I dug through some system logs from prior to
the change and found this:
AUTO LOGON *** SQLP0001 USERS = 101 BY SQLP0001
Is that the darnedest thing you ever saw?!?!? How can a virtual machine
which is NOT logged on execute AUTOLOG
On Mon, Jun 8, 2009 at 8:48 PM, Michael Coffinmichaelcof...@mccci.com wrote:
AUTO LOGON *** SQLP0001 USERS = 101 BY SQLP0001
Is that the darnedest thing you ever saw?!?!? How can a virtual machine
From what I recall it is APPC/VM causting the virtual machine to be
started to accept
a virtual
machine
which is NOT logged on execute AUTOLOG, and if it IS logged on and can
execute AUTOLOG, then it cannot be AUTOLOGged! This started the whole
chicken and egg analysis of course, and we were forced to make these
very
unusual servers AUTOONLY (with many comments
An AUTOONLY user cannot be used for authentication (obviously). An
LBYONLY user must authenticate with their own user ID. E.g. enter
maint.by.michael when ftp prompts for your user ID.
By golly, it works! Thanks much Alan, I hadn't seen that syntax until
you quoted it!
-Mike
...@listserv.uark.edu] On
Behalf Of Michael Coffin
Sent: Monday, June 08, 2009 2:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: A Strange Use Of AUTOLOG
An AUTOONLY user cannot be used for authentication (obviously). An
LBYONLY user must authenticate with their own user ID. E.g. enter
maint.by.michael when
Are you sure AUTOONLY doesn't work for BLDCMS, BLDNUC? It seems like it
should. Just make sure that the users that need to AUTOLOG these users
(e.g. MAINT, etc.) have the appropriate authority (e.g. a VM:Secure or
RACF rule allowing them to AUTOLOG without passwords, or an
AUTOLOG/XAUTOLOG card
Yet another common misunderstanding:
An AUTOLOG/XAUTOLOG card in the directory makes that a class G user
can XAUTOLOG the target user,
MAINT has sufficient CP classes to allow it to XAUTOLOG any virtual
machine, regardless of XAUTOLOG entries in the CP directory.
(and ESM can changed these rules
a virtual machine which is NOT logged on execute AUTOLOG, and if it IS logged on and can execute AUTOLOG, then it cannot be AUTOLOGged! This started the whole "chicken and egg" analysis of course, and we were forced to make these very unusual servers AUTOONLY (with many comments doc
In PROFILE.TCPIP, I have a TCPIP server (we'll call it server_a) listed
in the AUTOLOG directive. When server_a terminates, abends, etc, it
gets autolog'd and comes back up. However, there seems to be a fixed
number of times TCPIP does the autolog and then stops trying. Can the
number
)
listed in the AUTOLOG directive. When server_a terminates, abends,
etc, it gets autolog’d and comes back up. However, there seems to
be a fixed number of times TCPIP does the autolog and then stops
trying. Can the number of times autolog’d be changed? I looked
through the TCPIP P and C
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: TCPIP autolog retry
Steve,
This is controlled by the MAXRESTART statement in PROFILE TCPIP. The
default is 5.
Regards,
Miguel Delapaz
z/VM TCP/IP Development
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
11/20/2008 10:40:51 AM
Subject: Re: TCPIP autolog retry
Steve,
This is controlled by the MAXRESTART statement in PROFILE TCPIP. The
default is 5.
Regards,
Miguel Delapaz
z/VM TCP/IP Development
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
11/20/2008 10:40:51 AM:
In PROFILE.TCPIP, I have a TCPIP
] On
Behalf Of Alan Altmark
Sent: Thursday, October 02, 2008 10:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: AUTOLOG
On Thursday, 10/02/2008 at 04:05 EDT, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
Yes it was a privilege issue. Thanks again for all the responses!
Terry, you should
Hi
I am setting some parameters in my AUTOLOG2 PROFILE EXEC, but they do
not seem to be taking affect. Is there something else I am missing?
The 'CP XAUTLOG xxx' seems to be working fine but commands such as
the following do not take affect:
/* set recommended performance metrics
Are you sure the directory entry for AUTOLOG2 has the privilege
necessary to issue those commands?
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years
mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153
Yes, Virginia, there is a Slippery
:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR)
(CTR)
Sent: Thursday, October 02, 2008 12:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: AUTOLOG
Hi
I am setting some parameters in my AUTOLOG2 PROFILE EXEC, but
they do
Try this:
XAUTOLOG AUTOLOG2 SYNCH#SET SECUSER AUTOLOG2 *
That will let you watch the startup of AUTOLOG2 and see what might be
wrong.. as others have said - it's a good bet it's the privileges (or lack
of them) --
Scott Rohling
On Thu, Oct 2, 2008 at 1:33 PM, Martin, Terry R. (CMS/CTR) (CTR)
]
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Scott Rohling
Sent: Thursday, October 02, 2008 3:50 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: AUTOLOG
Try this:
XAUTOLOG AUTOLOG2 SYNCH#SET SECUSER AUTOLOG2 *
That will let you watch the startup of AUTOLOG2 and see
respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
AUTOLOG
Hi
I am setting some parameters in my AUTOLOG2 PROFILE EXEC, but they do not
seem to be taking affect. Is there something else I am missing?
The ?CP XAUTLOG xxx? seems
-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Walter
Sent: Thursday, October 02, 2008 4:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: AUTOLOG
Terry,
1) CP SET SRM commands require privclass 'A' (or a privclass for those
commands that you added another privclass
On Thursday, 10/02/2008 at 04:05 EDT, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
Yes it was a privilege issue. Thanks again for all the responses!
Terry, you should do those CP commands in AUTOLOG1's profile, before you
XAUTOLOG RACFVM. AUTOLOG2 doesn't need any privilege
I believe it used to be that we avoided AUTOCR for virtual machines
that start through AUTOLOG. The reason was that AUTOLOG stacks a line
to satisfy the console read from CMS. So when you would autolog a
virtual machine that had AUTOCR in the directory, it would leave that
extra line stacked
() will be 0
2008/7/15 Rob van der Heij [EMAIL PROTECTED]:
I believe it used to be that we avoided AUTOCR for virtual machines
that start through AUTOLOG. The reason was that AUTOLOG stacks a line
to satisfy the console read from CMS. So when you would autolog a
virtual machine that had AUTOCR
Yes to at least one of the questions, but aren't we all? ;-)
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij
Sent: Tuesday, July 15, 2008 2:08 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: autolog
Don't forget to also update SYSTEM NETID on MAINT 490 and 190 with the
CPUids for all the systems you plan on IPLing that pack.
Ideally what I'm looking for is a command that will retrieve the
system n
ame
(which I can't seem to find) and then I can start different linux
guests
based on that
CP QUERY IPLPARMS has nothing to do with the system name. If your
convention is FN maps to system name, that's OK for you. But FN is
not the system name.
CP QUERY GATEWAY may give some system name somehow. Not familiar
with all that GATEWAY implies.
CMS IDENTIFY says how CMS maps virtual
Others have already replied, and Alan pointed out the key differences
between the results of the CMS command IDENTIFY vs the CP command QUERY
USERID.
Here's a cut/paste (apologies to those reading this with text-only
capabilities) that addresses the same issue from my SHARE presentation
9120
On Friday, 01/26/2007 at 11:26 EST, Richard Corak [EMAIL PROTECTED]
wrote:
CP QUERY GATEWAY may give some system name somehow. Not familiar
with all that GATEWAY implies.
The GATEWAY and system identifer may be different. The system gateway (if
it hasn't been disabled in SYSTEM CONFIG)
Does anyone have an autolog profile exec that contains some logic to auto
log
different servers based on what system you are on? We are trying to get t
o a
point where we can quickly copy the res pack to other systems, and, based
on
the system config fn specified on salipl, ipl a copy of that res
We use: QUERY IPLPARMS
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mary Anne Link
Sent: Thursday, January 25, 2007 9:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: autolog profile exec logic
Does anyone have an autolog profile exec
and practice are the same, but
in practice, theory and practice are different.
From: Stracka, James (GTI) [EMAIL PROTECTED]
Reply-To: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
Date: Thu, 25 Jan 2007 09:45:41 -0500
To: IBMVM@LISTSERV.UARK.EDU
Conversation: autolog profile exec logic
After retrieving the system name, which others have shown how to do, use
it as the filename of a file containing the linux guests that should be
brought up on that system. Benefits over coding them directly in the
autolog PROFILE are that you only touch the code once (thus reducing
: Thursday, January 25, 2007 9:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
I tried Q IPLPARMS on my system, and get:
q iplparms
No IPL parameters are currently defined
Ready; T=0.01/0.01 08:56:31
directly in the
autolog PROFILE are that you only touch the code once (thus reducing the
likelyhood of a syntax error terminating the exec), and the PROFILE
becomes common code across all systems.
Brian Nielsen
On Thu, 25 Jan 2007 08:34:04 -0600, Mary Anne Link
[EMAIL PROTECTED] wrote:
Does
Duh. You know I use the ID command all the time and didn't notice sysname
.
Any thing you can send would be great. ([EMAIL PROTECTED])
Thanks for the IPLParms suggestion too. I should've figured that one, but
I'm not doing this yet so my iplparms doesn't show fn=vmlpar1 yet. :(
Thanks!!
PROTECTED] On Behalf Of RPN01
Sent: Thursday, January 25, 2007 9:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
I tried Q IPLPARMS on my system, and get:
q iplparms
No IPL parameters are currently defined
Subject: Re: autolog profile exec logic
I tried Q IPLPARMS on my system, and get:
q iplparms
No IPL parameters are currently defined
Ready; T=0.01/0.01 08:56:31
How does this tell me what system I'm on?
However
-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of RPN01
Sent: Thursday, January 25, 2007 9:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
I tried Q IPLPARMS on my system, and get:
q iplparms
: DOEVM01 Owning Userid: AVS
/Tom Kern
On Thu, 25 Jan 2007 08:34:04 -0600, Mary Anne Link [EMAIL PROTECTED]
M
wrote:
Does anyone have an autolog profile exec that contains some logic to aut
olog
different servers based on what system you are on? We are trying to get
On Thursday, 01/25/2007 at 08:34 CST, Mary Anne Link
[EMAIL PROTECTED] wrote:
We are trying to get to a
point where we can quickly copy the res pack to other systems, and,
based on
the system config fn specified on salipl, ipl a copy of that res pack to
bring up different systems.
You want
: autolog profile exec logic
Subject: Re: autolog profile exec logic
Someone at IBM thought this should be a class A command. Why a QUERY
command is class A is really beyond my comprehension.
But... since AUTOLOG1 is a class A machine it gives the results of the
SALIPL:
query iplparms
Current IPL
(GTI)
[EMAIL PROTECTED] wrote:
Well, to paraphrase, Nothing In, Nothing Out
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Ron Schmiedge
Sent: Thursday, January 25, 2007 10:22 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec
[EMAIL PROTECTED]
Reply-To: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
Date: Thu, 25 Jan 2007 10:44:37 -0500
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
On Thursday, 01/25/2007 at 08:34 CST, Mary Anne Link
[EMAIL PROTECTED] wrote:
We are trying to get
It is a trivial mod to SENDFILE to make it use a default id for the RSCS
userid if IDENTIFY returns '*'. I'm surprised it was never done by IBM.
Brian Nielsen
On Thu, 25 Jan 2007 10:44:37 -0500, Alan Altmark [EMAIL PROTECTED]
wrote:
On Thursday, 01/25/2007 at 08:34 CST, Mary Anne Link
AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
I have multiple configuration files on my sysres for use in Standalone
mode or at our hotsite, etc. I found that the System_Identifier entry in
the system config file will set the GATEWAY name in CP. You can then use
CP QUERY
@LISTSERV.UARK.EDU
Conversation: autolog profile exec logic
Subject: Re: autolog profile exec logic
Tom,
That QUERY GATEWAY is really slick. I like that even better than
QUERY IPLPARMS.
We keep unique CONFIG files on the PARM disks too.
Jim
Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of RPN01
Sent: Thursday, January 25, 2007 10:51 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: autolog profile exec logic
I am a class A user; What version of zVM
Uh oh. Why do I feel like a little mouse and Alan is the cat toying with
me. :)
Well, I guess I will copy spool as well. I can't think of a reason I woul
d
want to reuse SPL if I have replaced the res, so essentially I guess they
go
together. We only use SFS files for console logs so I can
We used to be very concerned with SPOOL file recovery in moving from one
configuration to another, but that was when we had real users. Now we don
't
have users who need their old spool file, just servers that are creating
new
console log spool files. I resurrected an old idea about saving DCSSes
As Robert Nix mentioned, the easiest and safest way to get the system nod
e
name is to use the CP QUERY USERID command. No dependencies on SYSTEM
NETID or IPLPARMS and it's a class G command, (anybody can use it). I us
e
it in lots of Execs to determine what system I am on. In a REXX Exec,
done the original work).
now as to automated operator /or automated operations ...
the *autolog* command ... mentioned here
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
helped significantly with the automation of service virtual machines
... some recent references
53 matches
Mail list logo
