Just curious: why one want to know acctnum of given person?
More general: what are acctnums used for nowadays?
Teaching RACF and z/OS I always recommend to set profile CL (ACCTNUM) *
UACC(R) and forget. Only one shop's employes had some rules on acctnum,
but even them didn't know what is the rationale behind.
Regarding reports: TSO information in RACF is not 1:1 from UADS, so some
reports cannot be simply converted. However this is side effect of
enhancements. For example there is difference between logon procedure
"in use" and allowed. The same apply to acctnum. User may have a choice
of many procedures and many (any) acctnums.
Regarding recovery: I would strongly recommend to use "one pack z/OS" or
any other form of tech system, another LPAR. That's waaaaaay more
convenient than failsoft processing with UADS.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2016-02-01 o 22:50, Skip Robinson pisze:
For the record, my comments on UADS vs. TSO segment have nothing to do with DR.
We mirror all DASD from production to recovery site, so everything in
production is available in DR. My point about querying a TSO segment is this:
when defining a userid with TSO segment, only the first of multiple proclibs or
account numbers are stored in the TSO segment itself. Any others are defined in
classes TSOPROC or ACCTNUM. While all proclibs and account numbers are
displayed via the ACCOUNT LIST command, with TSO segment you have to do
multiple queries.
In a previous shop, developers had multiple account numbers in order to track
their work by project. Not so much here, but many folks have multiple proclibs
for various purposes. Just last week I had to use my 'dataset free' emergency
proc in order to logon in the face of an unavailable dataset. I happen to have
a TSO segment myself because I need CONSOLE (TSOAUTH), but only a few sysprogs
have that requirement.
As for 'conversion' to TSO segment, we have a long-established security
management tool consisting of programs--many in COBOL!--that allow a handful of
security admins to manage hundreds of users and thousands of datasets across a
dozen LPARs. This tool is complex and installation-specific in a way that only
in-house developed software can be. There's a fenced-off section in the local
boot hill reserved for tombstones with inscriptions like this:
'Here lies Tony the Axe. Hired to kill off the security tool. Long live the
tool.'
.
.
.
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 Elardus Engelbrecht
Sent: Monday, February 1, 2016 08:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5)
John Eells wrote:
I hadn't really thought about (or researched) the display capabilities of RACF.
An RFE couldn't hurt if you find them lacking.
I don't think there is any problem with the display capabilities. Actually, you
use a RACF command or utility (RACF panels for example) to ask RACF
questions about the fields you're interested in.
Once one's TSO/E administrative routines have been converted to use the
TSO segment, though, I think another good use of UADS is for recovery,
including DR. It's the only way to log on when you have no security
database, at least when RACF is the absent DB in question. I'd want to
have "some number" of sysprog user IDs to be in UADS for recovery
purposes. (And an appropriate MPF exit, for RACF!)
Very true in all aspects.
As SA restore is a serial activity and batch restore is not, minimizing recovery
time would seem to call for a small number of UADS-defined IDs to speed
overall restore time if your security DB happens not to share a volume with
some other data sets required to IPL and log on. But what do I know?
Agreed. Just have a small UADS and test that out by RVARY inactive both your
RACF DBs. Preferably on a sandbox. ;-)
If you setup your RACF properly, you should have no trouble recovering it. Just
have your primary and backup RACF DB on separate volsers, make daily
backup with IRRUT200, do your DRP several times in a year, unload your RACF
DB using IRRDBU00, optionally run DBSYNC to generate commands to recreate
your RACF DB, etc.
I repeat - Just keep your RACF DBs on separate volsers, not on a IPL volser.
Skip Robinson wrote:
Ah, UADS. A prime example of archaic mechanism. Defensible technically?
Probably not, although a security administrator who needs to know which
account numbers or which proclibs a user is authorized to use might tell a
different story.
That is for fallback purposes. These days it is probably very seldom used.
But you should have documented your UADS+Proclibs and what ids are there
somewhere available during a DRP.
With UADS, a simple list command tells the story.
Yup, using ACCOUNT utility. There are CBT utilities available to help you with
that.
With TSOE segment, it's a data mining operation.
No. It is easy, just a LISTUSER <id> TSO. If you don't have access, ask for
access
to class FIELD, profile USER.TSO.* or ask for output from a fresh IRRDBU00 +
ICETOOL job.
This difference alone has inhibited conversion in some shops.
How so? What conversion? Can you give examples?
I may have missed something, but I did not fully followed the original COBOL
v5 thread and all these spawned threads.
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.
---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru
Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości
wpłacony) wynosi 168.955.696 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
