We have a number of userids that are only used with logonby.
I am aware that, if I set these up as NOPASSWORD, this prevents them
getting revoked as a result of someone erroneously trying to log on
directly. However, historically, we have not had this problem and these
userids have not been
/ibmvm@listserv.uark.edu/msg19233.html
http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg19239.html
On Tue, Mar 22, 2011 at 5:09 AM, Colin Allinson cgallin...@amadeus.com wrote:
We have a number of userids that are only used with logonby.
I am aware that, if I set these up as NOPASSWORD
No, NOPASSWORD will not stop revocation for inactivity. For that you need
the z/OS-inspired PROTECTED attribute. IBM is aware of the requirement.
Regards,
Alan Altmark
IBM Lab Services
-
Sent from my BlackBerry Handheld.
Bruce Hayden wrote:
In the current releases (5.4 and 6.1), you'll need to generate a
periodic dummy activity on the userid to keep it alive. In a future
release, nopassword/nophrase users will not be revoked due to
inactivity.
Also, here is a couple of posts on this from a few years ago:
On Tue, Mar 22, 2011 at 1:44 PM, Colin Allinson cgallin...@amadeus.com wrote:
Seems I am getting old and had forgotten that I had asked the self same
question before.
You're probably going to ask that every 60 days until it's resolved :-)
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
Thanks Alan.
In the interest of good citizenship I'll open a Sev 3 PMR.
Regarding NOPASSWORD, we do typically use that for SVMs, etc. Not this
time because of what I was testing.
Mark
At 11:32 AM 6/10/2009, Alan Altmark wrote:
FTP logon allows users in the ACL to use testuser.by.surrogate
:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: LOGONBY 8 user limitation
I'm trying to determine if RACF will allow me to bypass the 8 user limitation
imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add
operations staff to a virtual machine so they can respond to messages
RACF doesn't have a limit on the number of surrogate users that can
use the 'by' option of logon.
On Wed, Jun 10, 2009 at 12:52 PM, Dave Keetondave.kee...@state.or.us wrote:
I'm trying to determine if RACF will allow me to bypass the 8 user
limitation imposed with the LOGONBY attribute
RACF lets you define as many LOGONBY users for a target userid as you like.
RDEFINE SURROGAT LOGONBY.PERFSVM UACC(NONE)
and here we permit the staff to doLOGON PERFSVM BY staffx at z/VM logon
screen:
PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ)
PERMIT
Yes, this will work in RACF:
If using RACF, when you define the user as
LOGONBY, it can by default no longer be logged on to with its own
password (what is normally what you'd want). But, with an extra
command you can restore that possibility:
1. Define TERRY as LOGONBY
RAC RDEFINE
On Wednesday, 06/10/2009 at 02:16 EDT, Dave Keeton
dave.kee...@state.or.us wrote:
I'm trying to determine if RACF will allow me to bypass the 8 user
limitation
imposed with the LOGONBY attribute of the USER DIRECT entry. I need to
add
operations staff to a virtual machine so they can
On Wed, Jun 10, 2009 at 9:08 PM, Romanowski, John
(OFT)john.romanow...@cio.ny.gov wrote:
PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ)
Do yourself a favor and connect the various individuals to RACF groups
and then permit these groups to the logonby profiles. Even when you
Dave,
Using RACF you can have hundreds of logonby users, or you can group users
and authorize those groups to do logonby to a server.
We normally have a racf group for the system programmers, and grant that
racf group access to the logonby profiles for the server userids.
A similar setup is used
: LOGONBY 8 user limitation
Date: Wed, 10 Jun 2009 21:30:38 +0200
On Wed, Jun 10, 2009 at 9:08 PM, Romanowski, John
(OFT)john.romanow...@cio.ny.gov wrote:
PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ)
Do yourself a favor and connect the various individuals to RACF groups
Thanks, makes a lot of sense, I'll pass that on to our RACF admin.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Rob van der Heij
Sent: Wednesday, June 10, 2009 3:31 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: LOGONBY 8 user
/2009 14:44
Subject:
LOGONBY 8 user limitation
I'm trying to determine if RACF will allow me to bypass the 8 user
limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I
need to add operations staff to a virtual machine so they can respond to
messages and other tasks. I need
...@sco.idaho.gov
Subject: Re: Setting DIRM NEEDPASS NO in a LOGONBY user
To: IBMVM@LISTSERV.UARK.EDU
On Thu, 12 Feb 2009 09:21:59 -0500, Alan Altmark
alan_altm...@us.ibm.com
wrote:
This leads me to ask: Is NEEDPASS YES still needed? I view
it as an
anachronism from an older time when we didn't
On Mon, Feb 16, 2009 at 6:51 AM, Shimon Lebowitz shim...@iname.com wrote:
Having been asked just last week, by a member of the
system 'superuser' group, to increase his timeout-lockup
in the session manager from 10 to 20 (!) minutes,
I definitely agree with Brian!
Provided that the software
following the book as opposed to my own methods).
I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So,
it should have all RACF enablements.
MAINT is defined as a LOGONBY user and is logged on BY BUELENSC.
When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for
MAINT's
/VM Development
IBM Endicott
From my point of view I would have thought that this is not what you would
want. In our installation, for security reasons, privileged functions are
not carried out on personal userids and all privileged userids (including
MAINT) are LOGONBY. This means
(including
MAINT)
are LOGONBY. This means there is an audit trail of who did what.
MAINT has been set to 'DIRM NEEDPASS NO' for as long as I can remember
so I
can't remember how we did that in the first place but it is certainly
what we
would want. The alternative is for function
Alan Altmark alan_altm...@us.ibm.com wrote:
This leads me to ask: Is NEEDPASS YES still needed? I view it as an
anachronism from an older time when we didn't have autolock screensavers
and generally more stringent workstation security policies. No more
always on terminals.
Alan
On Thu, 12 Feb 2009 09:21:59 -0500, Alan Altmark alan_altm...@us.ibm.com
wrote:
This leads me to ask: Is NEEDPASS YES still needed? I view it as an
anachronism from an older time when we didn't have autolock screensavers
and generally more stringent workstation security policies. No more
I think whether NEEDPASS YES is still needed is an it depends and
should be left to the customer. What is needed, however, is a
re-engineering or a redesign or rethinking of how and where it is
defined in DIRMAINT. In talking to some developer in Endicott (don't
remember who), what came thru
On 2/12/09 9:21 AM, Alan Altmark alan_altm...@us.ibm.com wrote:
This leads me to ask: Is NEEDPASS YES still needed? I view it as an
anachronism from an older time when we didn't have autolock screensavers
and generally more stringent workstation security policies. No more
always on
Jim said:
=
I think whether NEEDPASS YES is still needed is an it depends and
should be left to the customer. What is needed, however, is a
re-engineering or a redesign or rethinking of how and where it is
defined in DIRMAINT. In talking to some developer in Endicott (don't
remember
Amen! Hear Hear.
On 2/12/09 11:03 AM, Jim Bohnsack jab...@cornell.edu wrote:
I think whether NEEDPASS YES is still needed is an it depends and
should be left to the customer. What is needed, however, is a
re-engineering or a redesign or rethinking of how and where it is
defined in DIRMAINT.
Technical Support
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Lionel B. Dyck
Sent: Thursday, February 12, 2009 10:11 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Jim said
We have VM:Secure, but the same question came up the other day. We have
application userids that have a number of developers authorized to use
LOGONBY, but the application owners don't want those developers to be
able to change the Rules files for those userids. They want that
authority
On Thursday, 02/12/2009 at 11:05 EST, Jim Bohnsack jab...@cornell.edu
wrote:
I think whether NEEDPASS YES is still needed is an it depends and
should be left to the customer. What is needed, however, is a
re-engineering or a redesign or rethinking of how and where it is
defined in DIRMAINT.
On Thursday, 02/12/2009 at 09:45 EST, Colin Allinson
cgallin...@amadeus.com wrote:
That is, indeed, a good point. In a well controlled environment, (good
attention paid to physical security as well as controlled authorities),
it
should not be needed. I am not sure, however, that it is
I'm installing z/VM 5.4 with Dirmaint and RACF (and this time
following the book as opposed to my own methods).
I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So,
it should have all RACF enablements.
MAINT is defined as a LOGONBY user and is logged on BY BUELENSC.
When I issue
I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So,
it should have all RACF enablements.
MAINT is defined as a LOGONBY user and is logged on BY BUELENSC.
When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for
MAINT's password:
- I'd say it should prompt for BUELENSC's passwo
VM:Secure would also prompt for MAINT's password, using the logic that even
if you had LOGONBY to a user ID, that wouldn't grant you the capability to
change the directory entry for that ID.
Bob Bolch
- I'd say it should prompt for BUELENSC's password
(I am not supposed to know MAINT's
enablements.
MAINT is defined as a LOGONBY user and is logged on BY BUELENSC.
When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for
MAINT's password:
- I'd say it should prompt for BUELENSC's password
(I am not supposed to know MAINT's password when using LOGONBY)
- So I enter
: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Monday, November 24, 2008 9:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: LOGONBY - limit of 8 userids.
On Monday, 11/24/2008 at 08:01 EST, David Kreuter
[EMAIL PROTECTED] wrote:
The LOGONBY statement
You probably know this, but I think that¹s a compelling argument for a ESM
and using ESM groups to manage LOGONBY authorization. It¹s going to be a lot
cheaper to get VM:Secure (dir mgmt and ESM all in one) than to hack
something up yourself. Use DIRM/RACF if you must, but buy it rather than
build
On Tue, Nov 25, 2008 at 7:37 AM, Shimon Lebowitz [EMAIL PROTECTED] wrote:
I once wrote a local mod to HCPRPI or whatever (I am at home
now) which allowed LOGONBY to a non-ESM system we have, based
on the ACIGROUP of the logging on user. The acceptable
ACIGROUPS were hardcoded in the mod, so
On Tuesday, 11/25/2008 at 07:52 EST, Wakser, David
[EMAIL PROTECTED] wrote:
Unless I am misreading things, wouldn't CP Exit 1101: Logon
Post-Parse Processing do exactly what he needs? He would have a list of
acceptable users in the exit, if it is any of them, he would change the
return code.
Since changes are a'coming
I like the idea of a new DIRMAINT/ESM authorization
LGNBYGRP acigname1 acigname2 ...
/Tom Kern
Alan Altmark wrote:
That wouldn't work. The exit is called after the LOGON command has been
parsed, but before LOGON has actually begun. No passwords validated
On Nov 25, 2008, at 9:43 AM, Alan Altmark wrote:
2) they must change as CP changes. [free advice: changes are a-
comin',
rollin' 'round the bend.]
Should we be using Folsom Prison Blues or Dylan's Slow Train as
our model?
Adam
On Tue, Nov 25, 2008 at 4:53 PM, Thomas Kern [EMAIL PROTECTED] wrote:
Since changes are a'coming
With Alan that's a threat, not a promise of desirable change.
And certainly not that you can pick you favorite change ;-)
Rob
On Tuesday, 11/25/2008 at 10:54 EST, Thomas Kern [EMAIL PROTECTED]
wrote:
Since changes are a'coming
I like the idea of a new DIRMAINT/ESM authorization
LGNBYGRP acigname1 acigname2 ...
I meant that changes in the ACI itself are coming that will require more
changes to more things in
On Tue, Nov 25, 2008 at 5:40 PM, Alan Altmark [EMAIL PROTECTED] wrote:
2. Create a list of target of target IDs so that you can change the list
of target IDs without have to do PERMITs.
How's that with RACF ? You can't group the targets unless they are so
similar that a generic profile does
On Tuesday, 11/25/2008 at 03:50 EST, Rob van der Heij [EMAIL PROTECTED]
wrote:
On Tue, Nov 25, 2008 at 5:40 PM, Alan Altmark [EMAIL PROTECTED]
wrote:
2. Create a list of target of target IDs so that you can change the
list
of target IDs without have to do PERMITs.
How's that with RACF
The LOGONBY statement in the directory is limited to 8 users. I have a client
that wants to have, say, 16 in the list.
The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, etc.
This isn't helping, as if DIRMAINT was there we could do a dynamic directory
update.
I have
David,
You didn't say anything about the userid that they're trying to log on
to. If all they need are some privileges that you don't want to grant
to their personal userids, can you have two, with eight LOGONBY users on
each, e.g. MAINT1 and MAINT2? Obviously, that won't work for some
things
On Monday, 11/24/2008 at 08:01 EST, David Kreuter
[EMAIL PROTECTED] wrote:
The LOGONBY statement in the directory is limited to 8 users. I have a
client
that wants to have, say, 16 in the list.
The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT,
products,
etc. This isn't
OTOH, completely outside the box, you could write a CMS that would allow one of
the authorized users, from their ID to contact (maybe SMSG) a server that has
access to the USER DIRECT, check that the target userid is not already logged
on, change one of the LOGONBY IDs in the USER DIRECT
is not already
logged
on, change one of the LOGONBY IDs in the USER DIRECT to their userid,
run
DIRECTXA, then CP MSG them to go ahead with LOGONBY.
It could be made more complex (change MAINT 2CC MDISK to RR, have the
server
dynamically LINK/DET the MAINT 2CC as needed, etc.), but that's
I once wrote a local mod to HCPRPI or whatever (I am at home
now) which allowed LOGONBY to a non-ESM system we have, based
on the ACIGROUP of the logging on user. The acceptable
ACIGROUPS were hardcoded in the mod, so you might not be
happy with my choices ;-) but if you want the code I can
the last time
anyone actually dialed to it. Again, 3270 emulators stole the show.
Why didn't I mention any them? Aside from forgetting them, because the
original question was asked by someone unfamiliar with the basics of
LOGONBY. Adding a session manager would definitely cloud the issue
or policies of Hewitt Associates.
David Boyes [EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
09/23/2008 07:37 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: LOGONBY
On 9/23/08 5:58 PM
On Wed, 24 Sep 2008 10:25:47 -0500 Mike Walter said:
OK, I'll byte. Is the most current TNVT100 located by google at:
http://ukcc.uky.edu/~tools/1997
Or is a newer one located somewhere beyond google's wide vision?
There have been minor tweaks since 1997.
Cheers,
Arty
OK, I'll byte. Is the most current TNVT100 located by google at:
http://ukcc.uky.edu/~tools/1997
Or is a newer one located somewhere beyond google's wide vision?
That's the version I have. I don't think Arty's done anything to it in a
very long while.
Emacs on a 3270 is a very strange
Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Wednesday, September 24, 2008 7:56 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: LOGONBY
David,
Aside from a test, I never installed Arty's Session. For
years
On Tue, Sep 23, 2008 at 6:05 AM, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
So the only thing you are buying here is that you keep TCPMAINT password
secret is that the whole idea behind LOGOnBY? So then you only add
certain user ids to do LOGONBY for this user id correct
So the only thing you are buying here is that you keep TCPMAINT
password
secret is that the whole idea behind LOGOnBY? So then you only add
certain user ids to do LOGONBY for this user id correct?
Think of it more as a role: you are assuming the role of TCPMAINT, using
your own login
And it makes it easy to revoke privileges from a user: just remove the
LOGONBY authority. This is handy in an environment where roles change
frequently. And if the person leaves or retires, deleting the User ID
takes care of all access, without scrambling to remember which
seldom-used accounts
Not mentioned yet. If using RACF, when you define the user as
LOGONBY, it can by default no longer be logged on to with its own
password (what is normally what you'd want). But, with an extra
command you can restore that possibility:
1. Define VMUTIL as LOGONBY
RAC RDEFINE SURROGAT
Is LOGONBY a RACF thing or z/VM???
T.y.
Graves Nora E [EMAIL PROTECTED] 9/23/2008 8:59 AM
And it makes it easy to revoke privileges from a user: just remove the
LOGONBY authority. This is handy in an environment where roles change
frequently. And if the person leaves or retires, deleting
On Tue, Sep 23, 2008 at 3:33 PM, Howard Rifkind [EMAIL PROTECTED] wrote:
Is LOGONBY a RACF thing or z/VM???
It is easier with RACF, but CP also has directory statements that support it.
Rob
Howard Rifkind wrote:
Is LOGONBY a RACF thing or z/VM???
T.y.
No, it is not a RACF thing...it's part of the native CP user facilities. It can be used
with RACF, or your ESM of choice.
Graves Nora E [EMAIL PROTECTED] 9/23/2008 8:59 AM
And it makes it easy to revoke privileges
On Tue, Sep 23, 2008 at 3:27 PM, Kris Buelens [EMAIL PROTECTED] wrote:
I never set tis up for a user like VMUTIL, but only to be able to
logon to my colleague's userid with my password when he was on
vacation (and a alike for my user when I was on vacation).
And that's exactly why you should
One thing not mentioned by others (unless I missed it) - if you have
VM:Secure for your ESM, if you use logonby to log on to a userid, say
ALAN for purposes of discussion, and try to use VM:Secure to change any
of the security settings, you must give the logged on machine's password
in response
Terry,
LOGONBY has been around for many VM releases. We set all our service
machine accounts and important maintenance ids (MAINT, TCPMAINT, etc)
up with a LOGONBY list. Then we change those ids' passwords to
LBYONLY, which says the userid can only be logged on using LOGONBY. So
if you try
It's controllable by RACF, but is part of CP (finally).
Is LOGONBY a RACF thing or z/VM???
LOGONBY has been a part of CP since before VM/ESA 2.3 (1998). It is not mentioned in the Quick
Reference for VM/SP 6 (1988) so it was added between 1988 and 1998. It has been around a long time.
Maybe even longer that RACF. (I don't know when it was introduced on VM.)
David Boyes wrote:
It’s
Before VM got LOGONBY, IBM had internally a RACF modification that
allowed a Logon By, for ages. Obviously, CP was not aware of the
LOGONBY, (so no Q BYUSER for example). CP was even fooled: on the
password prompt one'd enter
byuser/byuserpswd/byuserpswd
that is, for CP it looked like
Rob van der Heij wrote:
Actually, the better solution is to have *no* password for TCPMAINT.
You can with z/VM 5.3. Without a password, the TCPMAINT user can not
be revoked by incorrect logon attempts. If it were revoked, the
authorized people could not even logon to it with logonby. Also, you
It was a user mod for a while (pre-XA). I think VM/XA or VM/ESA 1.x was
when it became official. That was a long time ago, though.
I know I had it on SP5 as a usermod and remember that I was really glad
to not have to maintain it any more.
David Boyes wrote:
It was a user mod for a while (pre-XA). I think VM/XA or VM/ESA 1.x was
when it became official. That was a long time ago, though.
I know I had it on SP5 as a usermod and remember that I was really glad
to not have to maintain it any more.
A very long time...
On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L
Dennis.L.O'[EMAIL PROTECTED] wrote:
Be careful about what *no* password means. Rob is talking about RACF.
The directory allows a password of NOPASS, which might seem to be the
obvious thing if you don't read the manual. NOPASS actually
Just logon to MAINT using LOGONBY with your personal userid/pw
Scott Rohling
On Tue, Sep 23, 2008 at 3:58 PM, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
Hi
One last thing on this. Am I logged on with my user id and password then
from there logonby to another machine
No, you cannot logon to one userid when logged onto another.
When already logged on, the process is CP LOGoff (or CP DISConnect).
Then you get a logo screen and can logon using LOGONBY. Personally, I'd
just clear the logon screen, and logon from a blank screen.
The command entry from a cleared
] On
Behalf Of Scott Rohling
Sent: Tuesday, September 23, 2008 6:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: LOGONBY
Just logon to MAINT using LOGONBY with your personal userid/pw
Scott Rohling
On Tue, Sep 23, 2008 at 3:58 PM, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
Hi
One last
Your id need not be logged on. You can logon to more than one id using
logonby. When I am testing tools for our TPF testers, I frequently have
up to 6 concurrent ids that I have logged on via logonby.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
Just to clarify -- you can be logged on to your own userid if you like..
just bring up another session and logonby to maint with your userid/pw.
Just want to be sure you understand that being logged on to your own userid
has no bearing at all on being able to logonby to another userid...
Scott
Hi
One last thing on this. Am I logged on with my user id and password then
from there logonby to another machine such as MAINT? Or do I just logon
to MAINT using LOGONBY with my personal user id's password?
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS z/VM Systems
Geez. 28 years. Now I really feel officially ancient. Thanks a lot, dude.
On 9/23/08 5:44 PM, Dave Wade [EMAIL PROTECTED] wrote:
David Boyes wrote:
A very long time...
http://vm.marist.edu/~vmshare/browse?fn=DMKLOGft=MEMO
http://vm.marist.edu/~vmshare/browse?fn=NOPSWDft=NOTE
On 9/23/08 5:58 PM, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
Hi
One last thing on this. Am I logged on with my user id and password then
from there logonby to another machine such as MAINT? Or do I just logon
to MAINT using LOGONBY with my personal user id's password
On 9/23/08 6:14 PM, Mike Walter [EMAIL PROTECTED] wrote:
No, you cannot logon to one userid when logged onto another.
Mike! What happened to your copy of SESSION?
Native CP can't do it, but you certainly can use SESSION or YVETTE or NV/AS
or PVM to get multiple login sessions from a single
Hi
So if I understand LOGONBY it simply allows a user to logon to lets say
TCPMAINT using the user's own PASSWORD. Does this mean you still use
TCPMAINT as the userid?
Thanks,
Terry
On Monday, 09/22/2008 at 11:09 EDT, Martin, Terry R. (CMS/CTR) (CTR)
[EMAIL PROTECTED] wrote:
So if I understand LOGONBY it simply allows a user to logon to lets say
TCPMAINT using the user?s own PASSWORD. Does this mean you still use
TCPMAINT
as the userid?
LOGON TCPMAINT BY ALAN
enter
Hi Alan,
So the only thing you are buying here is that you keep TCPMAINT password
secret is that the whole idea behind LOGOnBY? So then you only add
certain user ids to do LOGONBY for this user id correct?
Thanks,
Terry
-Original Message-
From: The IBM z/VM Operating System [mailto
So if I understand LOGONBY it simply allows a user to logon to lets say
TCPMAINT using the user's own PASSWORD. Does this mean you still use
TCPMAINT as the userid?
That's correct. LOGONBY will let a user logon to TCPMAINT using his own
userid and password of his own userid (the command
Hi Listers,
Is there a way to get FTP clients like Bluezone, WS-FTP etc to work with
z/VM users that use LOGONBY?
Regards,
Fred Schmidt
Department of Corporate and Information Services (DCIS)
Data Centre Services (DCS)
Northern Territory Government, Australia
On Sunday, 07/13/2008 at 07:57 EDT, Fred Schmidt [EMAIL PROTECTED]
wrote:
Is there a way to get FTP clients like Bluezone, WS-FTP etc to work with
z/VM
users that use LOGONBY?
Configure them with your user id as userid/by/yourid or userid.by.yourid
Alan Altmark
z/VM Development
IBM
90 matches
Mail list logo
