But the only way to "fix"an unusable RACF database is to have a fairly
recent backup copy of the RACF data base that can be restored. I would
contend that is easier, and possibly safer, to do this from a fully
functional "one-drive" tech support emergency z/OS system accessing
production drives than to do it from a UADS-defined TSO user on a
crippled production system without RACF or with a known-damaged database
-- and there are so many other unanticipated problems such an emergency
system can address that it doesn't make sense to be without one.
If the only problem that can be solved by having a UADS-defined TSO user
can be better addressed by a "must have" alternative, why persist with
any UADS-defined TSO users once the alternative is available?
Joel C. Ewing
On 02/14/2016 01:04 PM, Skip Robinson wrote:
> This problem occurs so seldom that I never thought of automating a response.
> As of R12 or so, we now have AUTORxx, which can reply to WTORs very early in
> the IPL. Not sure who here would have to approve such a change. The chances
> of mischief being perpetrated are minimal, but it does open a very small
> window for a clever miscreant.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
>
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Ed Jaffe
>> Sent: Sunday, February 14, 2016 07:37 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)
>>
>> On 2/13/2016 8:04 PM, Skip Robinson wrote:
>>> This opinion is based on (thankfully) limited experience. If you are
>>> forced to IPL without a usable RACF data base, you are totally
>>> scr*wed. During IPL, operator will be prompted to allow even READ
>>> access to *every* data set opened by *every* task except for a tiny
>>> handful like JES that bypass integrity. By the time you get to the
>>> point of actually logging on to TSO, operator's fingers will be
>>> bleeding profusely. If at any time during this process, you are
>>> god-forbid required to start over, yet more finger tips will have to
>>> sacrificed.
>> We solved this with an MPF exit that would always reply 'Y' to each of those
>> prompts (except for the first few IIRC).
>>
>> --
>> Edward E Jaffe
>> Phoenix Software International, Inc
>> 831 Parkview Drive North
>> El Segundo, CA 90245
>> http://www.phoenixsoftware.com/
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
