Colin, Close. But the "Don't change what IBM provide" rule is one I do not adhere to.
Over 50 years of MVS to z/OS experience including about 45 years of RACF experience has taught me that RACF rarely has a "one way fits all" scenario. I will make whatever changes I need to make. I do not stick to what a few guys in Texas chose as their way to do things. My zPDT (which will soon rest in peace/pieces) is vastly different from what is delivered by each ADCD release. I have locally documented procedures for turning that one ADCD configured system into three IPLable systems all running from the same token. Each system has its own RACF database, its own set of non-SMS and SMS volumes and SMS rules and catalogs with HLQs. They each have volume backup routines which run over NFS to multiple NAS devices too. They communicate with one another over my local network, via FTP, NJE and a zSecure network. If it was likely to survive this year, I may have set about tinkering with an RRSF network too. But it is all heading for the scrap heap, courtesy of IBM's policy changes. Lennie -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Colin Paice Sent: 06 March 2026 07:47 To: [email protected] Subject: Re: Mainframe ID's Lennie, I think we are in agreement. - You should use groups to give access to resources. - On the ZD&T system some resources have only userids with access. - Don't change what IBM provide My program (which recreates the RACF command string) just recreates what exists, even if the configuration is not best practice. Colin On Fri, 6 Mar 2026 at 00:03, Lennie Bradshaw <[email protected]> wrote: > Colin, > I don't fully understand your point. > Are you saying that access to those resources should not be given via > a group connect? > > Granting access via a connect is usually faster than a permit as you > can avoid a logon/logoff sequence. > You say you have 10 userids and no groups. (That cannot be true as > each userid has to be a member of at least 1 group). > But why not create the groups you need? > > I have been running a zPDT for upwards of 15 years both in and out of IBM. > If things are delivered in a way that is not best, then I change it. > Or maybe I have missed your point? > > Lennie > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Colin Paice > Sent: 05 March 2026 14:58 > To: [email protected] > Subject: Re: Mainframe ID's > > Lennie, > > I know about not giving userids access to resources (see Jump up and down: > Do not give userids access to resources! > < > https://colinpaice.blog/2025/05/25/jump-up-and-down-do-not-give-userid > s-access-to-resources/ > > > ) I've been dealing with the zD&T system from IBM with resources like > > - FACILITY BPX.CONSOLE with access to IBMUSER, IZUSVR, CFZSRV, > TCPIP and > - FACILITY BPX.DAEMON with 10 userids and no groups! > > I wrote my program to extract the userid profiles for this environment. > > Colin > > > On Thu, 5 Mar 2026 at 11:13, Lennie Bradshaw > <[email protected]> > wrote: > > > Colin, > > > > Most well-organised RACF shops will not allow RACF users in access lists. > > Access is manipulated using permits to groups and group connects to > > RACF users. > > That makes cloning a user far easier as for access purposes you > > identify the group connects. > > > > Lennie > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > > Behalf Of Colin Paice > > Sent: 05 March 2026 09:56 > > To: [email protected] > > Subject: Re: Mainframe ID's > > > > I understand. > > > > I used my code to replicate a userid by running my program and > > changing COLIN to COLIN1 in the output. > > My program will not help if individual userids (rather than groups) > > have access to a resource; you have to look at every resource to > > find the id's access. > > > > Colin > > > > On Thu, 5 Mar 2026 at 08:35, ITschak Mugzach < > > [email protected]> wrote: > > > > > Colin, > > > > > > I think that Steve talked about copying a user, not just create one. > > > In racf it is a two step task, first collect information from the > > > name utility and than look which authority the user have on the > resource. > > > Alternatively usr the unload utility > > > > > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** > > > IronSphere > > > Platform* *|* *Information Security Continuous Monitoring for > > > Z/OS, zLinux and IBM I **| * > > > > > > *|* *Email**: [email protected] **|* *Mob**: +972 522 > > > 986404 > > > **|* > > > *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* > > > > > > > > > > > > > > > > > > בתאריך יום ה׳, 5 במרץ 2026 ב-9:42 מאת Colin Paice < > > > [email protected]>: > > > > > > > I have a program (under development) which recreates the RACF > > > > command > > > used > > > > to create a used/dataset/resource profile. > > > > You pass parameters U COLIN > > > > It generates > > > > ADDUSER COLIN > > > > > > > > CONNECT COLIN GROUP(IZUADMIN) UACC(READ) SPECIAL AUDITOR - > > > > REVOKE(01/01/27) - > > > > RESUME(01/02/27) > > > > CONNECT COLIN GROUP(IZUUSER) UACC(NONE) > > > > CONNECT COLIN GROUP(SYS1) UACC(NONE) - > > > > REVOKE(01/01/27) - > > > > RESUME(01/02/27) > > > > > > > > ALTUSER - > > > > COLIN - > > > > OWNER (COLIN) - > > > > NOADSP - > > > > NOOPERATIONS - > > > > NOGRPACC - > > > > NAME ('CCPAICE') - > > > > DFLTGRP (TEST) - > > > > DATA ('COLIN''S WITH A QUOTE') - > > > > NOAUDITOR - > > > > CLAUTH (CSFSERV) - > > > > NOREST - > > > > NOROAUDIT - > > > > WHEN( - > > > > DAYS (SUNDAY - > > > > MONDAY - > > > > TUESDAY - > > > > WEDNESDAY - > > > > THURSDAY - > > > > FRIDAY - > > > > SATURDAY) - > > > > TIME (ANYTIME)) > > > > ALTUSER - > > > > COLIN - > > > > TSO (ACCTNUM ('ACCT#') - > > > > COMMAND ('ex ''colin.zlogon.clist''') - > > > > PROC (ISPFPROC) - > > > > SIZE (2096128) - > > > > MAXSIZE (2096128) - > > > > USERDATA (0000) - > > > > UNIT (3390)) > > > > ALTUSER - > > > > COLIN - > > > > OMVS (UID (990021) - > > > > HOME ('/u/tmp/zowet/colin') - > > > > PROGRAM ('/u/zopen/usr/local/bin/bash') - > > > > MMAPAREAMAX (16777216) - > > > > SHMEMMAX (300M)) > > > > > > > > > > > > Is this what you are after ? > > > > > > > > Colin > > > > > > > > > > > > On Wed, 4 Mar 2026 at 20:35, Steve Beaver < > > > > [email protected]> wrote: > > > > > > > > > We have all struggled with replicating a TSO id without > > > > > something like > > > > VRA > > > > > or zSecure > > > > > > > > > > > > > > > > > > > > I'm learning more about TSS - it has a convent command > > > > > > > > > > > > > > > > > > > > TSS RENAME(acid) ACID(new acid) > > > > > > > > > > > > > > > > > > > > That works nicely. The only thing you really need to do is > > > > > DEFINE an > > > > ALIAS > > > > > and rename the datasets provided there are no a billion of > > > > > them > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > -- > > > > > ---- For IBM-MAIN subscribe / signoff / archive access > > > > > instructions, send email to [email protected] with the > > > > > message: INFO IBM-MAIN > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > -- > > > > -- > > > > -- For IBM-MAIN subscribe / signoff / archive access > > > > instructions, send email to [email protected] with the > > > > message: INFO IBM-MAIN > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO > > > IBM-MAIN > > > > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
