At the late great Security Pacific Bank, much care and effort were taken for chargeback to business units. This resulted in actual bills (internal funny money of course) based on system usage. A fairly elaborate account number schema supported this activity. Account numbers were tied to projects and were strictly controlled. A user had to be permitted to use a particular account number. Accounting/chargeback was done for batch via job card and online via TSO account number. It was imperative for admins to track all of this. Listing a TSO userid would show what account numbers/projects the user was set up for.
I'm not sure all this overhead was worth the cost, but it was the law of that land. . . . 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 R.S. > Sent: Tuesday, February 2, 2016 02:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) > > 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- > m...@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
