On 11/22/2005 10:57 AM, Patrick Lyon wrote:
On Tue, 22 Nov 2005 08:33:25 -0600, Dave Butts [EMAIL PROTECTED]
wrote:
Patrick,
I can't speak for ACF2 or RACF, but the conversion to Top Secret is
incredibly simple. One of the TSS manuals has a chapter on how to do it.
It is as simple as running
On Wed, 23 Nov 2005 08:16:57 -0500, Walt Farrell [EMAIL PROTECTED]
wrote:
The conversion utility is part of TSO/E, and is called RACONVRT. Look
in the TSO/E Customization manual for information.
As I recall it does not copy the user's logon command (from the logon
panel) during the conversion
On Mon, 21 Nov 2005 17:15:40 EST, Ed Finnell [EMAIL PROTECTED] wrote:
If nobody can use it, won't hurt to bounce TSO. Just wondering
what else is mis-cataloged. Broadcast, RACF, PROCLIBs,PARMLIBs.
Thanks for the response Ed. Nope, tried it this morning, I deleted my
member out of the UADS on
On Mon, 21 Nov 2005 19:30:29 -0800, Keith E. Moe [EMAIL PROTECTED]
wrote:
UADS in allocated in the Master JCL. There is no standard mechanism to
deallocate and reallocate. You must re-IPL.
In general, UADS should only be used for emergency User IDs, i.e., when
the security system (RACF, ACF2,
In a message dated 11/22/2005 7:02:49 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Everything else is fine - I just missed it in looking at my listcat of my
new mcat prior to conversion.
One blemish on the conversion, guess I can live with that!
If it's just bad UADS, can you
Patrick,
I can't speak for ACF2 or RACF, but the conversion to Top Secret is
incredibly simple. One of the TSS manuals has a chapter on how to do it.
It is as simple as running a batch job to perform the conversion.
HTH, Dave
On Mon, 21 Nov 2005 23:48:02 -0600, Ed Gould [EMAIL PROTECTED] wrote:
There is always something that can break, although I have never heard
of UADS breaking.
You just did :)
-Rob
--
For IBM-MAIN subscribe / signoff / archive
On Tue, 22 Nov 2005 09:33:13 EST, Ed Finnell [EMAIL PROTECTED] wrote:
If it's just bad UADS, can you just copy the good UADS to the bad
one(or just one userid for proof of concept)?
Ed, it was not a matter of a bad UADS, it was a UADS that I created
during system creation, a copy of our
As long as you don't grow the wrong UADS into a brand new extent (since MSTJCL
has already built a DEB), you could copy entries from the good UADS to the bad
one let TSO users logon until it is convenient for you to IPL
Patrick Lyon [EMAIL PROTECTED] wrote: Thanks for the response Keith. This
in the old UADS.
tb
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Dave Butts
Sent: Tuesday, November 22, 2005 8:33 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SYS1.UADS - when is it read?
Patrick,
I can't speak for ACF2 or RACF
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Patrick Lyon
Sent: Tuesday, November 22, 2005 9:38 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SYS1.UADS - when is it read?
On Tue, 22 Nov 2005 08:33:25 -0600, Dave Butts [EMAIL PROTECTED]
wrote
On Nov 22, 2005, at 9:45 AM, Rob Wunderlich wrote:
On Mon, 21 Nov 2005 23:48:02 -0600, Ed Gould
[EMAIL PROTECTED] wrote:
There is always something that can break, although I have never heard
of UADS breaking.
You just did :)
Rob,
Maybe I missed something... but I don't consider what was
Hi list - I had an issue implenting z/OS this past weekend that had to do
with having the wrong SYS1.UADS cataloged. After cataloging the correct
dataset, people are still receiving the Not Authorized to use TSO
message, so apparently something in the system is still looking at the
wrong UADS
In a message dated 11/21/2005 3:41:15 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
I am wondering if recycling the TSO address space will correct this issue
or will an IPL be necessary as SYS1.UADS is in the MSTJCL parmlib member.
Does anyone know?
If nobody can use it, won't
I am wondering if recycling the TSO address space will correct this issue
or will an IPL be necessary as SYS1.UADS is in the MSTJCL parmlib member.
Does anyone know?
UADS in allocated in the Master JCL. There is no standard mechanism to
deallocate and reallocate. You must re-IPL.
In general,
On Nov 21, 2005, at 9:30 PM, Keith E. Moe wrote:
I am wondering if recycling the TSO address space will correct
this issue
or will an IPL be necessary as SYS1.UADS is in the MSTJCL parmlib
member.
Does anyone know?
UADS in allocated in the Master JCL. There is no standard
mechanism to
16 matches
Mail list logo
