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
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:
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'm posting this question for a co-worker who is working on our conversion from
z/VM 5.3 to 5.4.
I've got three z/VM LPARs that share a RACF database. It is not shared with
any other systems.
The LPARs were running z/VM Version 5 Release 3.0, service level 1001 (64-bit).
I upgraded one of
I'm posting this question for a co-worker who is working on our conversion from
z/VM 5.3 to 5.4.
I've got three z/VM LPARs that share a RACF database. It is not shared with
any other systems.
The LPARs were running z/VM Version 5 Release 3.0, service level 1001 (64-bit).
I upgraded one of
On Tuesday, 01/18/2011 at 02:56 EST, Feller, Paul pfel...@aegonusa.com
wrote:
I've got three z/VM LPARs that share a RACF database. It is not shared
with
any other systems.
The LPARs were running z/VM Version 5
@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: RACF question
On Tuesday, 01/18/2011 at 02:56 EST, Feller, Paul pfel...@aegonusa.com
wrote:
I've got three z/VM LPARs that share a RACF database. It is not shared
with
any other systems.
The LPARs were running z/VM Version 5 Release
Support
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Alan Altmark
Sent: Tuesday, January 18, 2011 2:34 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RACF question
On Tuesday, 01/18/2011 at 02:56 EST, Feller, Paul pfel...@aegonusa.com
wrote
Technical Support
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Tuesday, January 18, 2011 2:34 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RACF question
On Tuesday, 01/18/2011 at 02:56 EST, Feller, Paul pfel
Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Tuesday, January 18, 2011 2:34 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RACF question
On Tuesday, 01/18/2011 at 02:56 EST, Feller, Paul pfel...@aegonusa.com
wrote:
I've got three z/VM LPARs that share a RACF
On Tuesday, 01/18/2011 at 04:27 EST, Feller, Paul pfel...@aegonusa.com
wrote:
Thanks Alan, I forwarded your reply to my co-worker and he came back
with some
more comments/questions. I'm not sure what , if anything, he has heard
from
the support center.
Since there's a PMR open, we don't
On Tuesday, 01/18/2011 at 04:50 EST, Kris Buelens kris.buel...@gmail.com
wrote:
The MDISK statements prove that the RACF database minidisks are not
fullpack,
hence CP wil not let Reserve/release propagate to the HW, hence RACFs in
multiple z/VM systems can both perform updates concurrently
On Tuesday, 01/18/2011 at 04:51 EST, Scott Rohling
scott.rohl...@gmail.com wrote:
The DASD is defined as shared - but if you're really sharing this RACF
database
- the 200 and 300 minidisks need to be fullpack minidisks. Cylinder 0
to END.
(DEVNO disks are recommended)
I'm not saying
I second that emotion :-) SETROPTS SHAREDB(YES) or some such
incantation... RACF could go into 'read only' mode if it finds things
amiss.
Scott Rohling
On Tue, Jan 18, 2011 at 4:12 PM, Alan Altmark alan_altm...@us.ibm.comwrote:
On Tuesday, 01/18/2011 at 04:51 EST, Scott Rohling
What you're asking for used to be called DWIM (Do What I Mean). There
was a package on the IBM internal tools disk 25 years ago or so called
that. Never really had the guts to try it out.
Jim
On 1/18/2011 6:12 PM, Alan Altmark wrote:
On Tuesday, 01/18/2011 at 04:51 EST, Scott Rohling
As I recall - DWIM was a CMS based 'command corrector' .. it didn't do
anything like check your system/DASD configuration - it would try and self
correct finger checks to commands you entered. But I understand the
correlation with *intent* in this case :-)
Scott Rohling
On Tue, Jan 18, 2011 at
@LISTSERV.UARK.EDU
Subject: Re: RACF question
The DASD is defined as shared - but if you're really sharing this RACF database
- the 200 and 300 minidisks need to be fullpack minidisks. Cylinder 0 to END.
(DEVNO disks are recommended)
I'm not saying this is the cause of the problem you are seeing
Happy New Year folks - I need a sanity-check, please ...
I've not used RACF on VM for a few decades and I believed that, as z/OS
advanced, there came a time when it was no longer possible to share a RAC
F
database between a z/VM system and a z/OS system. I'm sure that this bel
ief
was based upon
Jeff,
We used to do this until recently, it worked well and we would be still if
someone had not done a silly that would have caused too much effort to
resolve.
When you are running stable versions of RACF on both Z/OS and Z/VM then
there is no issue. The thing that you have to be aware of is
@LISTSERV.UARK.EDU
Date:
05/01/2011 10:12
Subject:
Simple RACF Question - Can the RACF database be shared with z/OS?
Sent by:
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
Happy New Year folks - I need a sanity-check, please ...
I've not used RACF on VM for a few decades and I believed that, as z
gclo...@br.ibm.com wrote :-
Jeff,
The last time I read about, all RACF documents says that it is possible.
But, only when the zOS doesn't work in Sysplex. This restriction killed
my chances to do tests...
Clovis
We were successfully sharing with a Z/OS sysplex so this is not an
On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin
jeff.grib...@gmail.com wrote:
I've not used RACF on VM for a few decades and I believed that, as z/OS
advanced, there came a time when it was no longer possible to share a
RACF
database between a z/VM system and a z/OS system. I'm sure that
] On Behalf
Of Alan Altmark
Sent: Wednesday, January 05, 2011 9:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Simple RACF Question - Can the RACF database be shared with z/OS?
On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin
jeff.grib...@gmail.com wrote:
I've not used RACF on VM for a few
Alan Altmark alan_altm...@us.ibm.com wrote:-
I am the one who has suggested publicly that just because you *can*
share,
it does not follow that you *should* share.
I fully understand and respect Alan's views on the Con's of sharing RACF
databases - but there are some Pro's as well. One of
Thankyou Alan - that succinctly lifts my understanding to the level
of, It's physically possible but really, really inadvisable because
... followed by exactly the concerns that I would have felt compelled
to raise here had the consensus been that it really was as easy as the
manual appears to
We have a RACF database that used to be shared between z/OS VM but, for
various reasons, this got split just over a year ago.
We have now run into a new problem and I need to understand why so that I
can formulate a solution :-
- There are VM userids, that never log on to z/OS (they
On Monday, 11/03/2008 at 03:59 EST, Colin Allinson
[EMAIL PROTECTED] wrote:
- If the user does not attempt to log on to TSO (or user one of the
password
protected TCPIP functions) there will be no requirement to change
password for
just job submission.
- A job submission will reset the
Alan said a couple of weeks ago that setting a user to NOPASSWORD
would completely remove the password and phrase and that these are
true:
- No one can logon directly to or use the id for authentication
- The user can still be XAUTOLOGed
- The user will never be revoked due to inactivity or too
I know that you can avoid a userid being revoked due to failed logon
attempts by setting it as NOPASSWORD (when this is an autologged service
machine or a target of LOGONBY).
Does the same apply to prevent users becoming revoked due to the defined
period of inactivity being exceeded?
We have
On Wednesday, 10/08/2008 at 08:07 EDT, Bruce Hayden [EMAIL PROTECTED]
wrote:
Alan said a couple of weeks ago that setting a user to NOPASSWORD
would completely remove the password and phrase and that these are
true:
- No one can logon directly to or use the id for authentication
- The user
*I* double-checked with TPTB and, the way things are today, the user
WILL be revoked for inactivity.
It's on the list of things he WANTs to fix, but it's not on the FIXED
list. And other than setting the password or logging on (with a valid
password), you aren't going to reset the Last
33 matches
Mail list logo
