In failsoft mode (no viable RACF active) SAF requests access via CONSOLE WTOR for each and every access to any and all datasets, regardless of DSCB bits
> -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Seymour J Metz > Sent: Monday, November 25, 2024 12:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > > Again, where are the WTORs coming from if you have no discrete profiles? > There's nothing else that turns on that DSCB bit for non-VSAM datasets. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Radoslaw Skorupka <00000471ebeac275-dmarc- > requ...@listserv.ua.edu> > Sent: Monday, November 25, 2024 3:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > > External Message: Use Caution > > > Disregard my previous answer, because it was wrong. > However you're wrong too. > > The answer is there are NO PROFILES. No profiles, because it is failsoft > mode. That means RACF is unable to answer to authorisation request. In > that case no general resources resources are checked (it is not wrong, > the repetition is correct). However every dataset access is checked > through WTOR. > Failsoft mode could mean damaged RACF db. That means it is impossible to > check the profile since it can be damaged. > > Regarding my previous answer: I'm pretty sure I did not use discrete > dataset profiles (some exceptions are not important here). > When needed, I used fully qualified general profiles. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > W dniu 25.11.2024 o 16:55, Seymour J Metz pisze: > > Yes, *discrete* dataset profiles. Which is exactly what I inferred and you > questioned. > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > עַם יִשְׂרָאֵל חַי > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Radoslaw Skorupka <00000471ebeac275-dmarc- > requ...@listserv.ua.edu> > > Sent: Monday, November 25, 2024 9:57 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > > > > External Message: Use Caution > > > > > > WTORs mean DATASET profiles. > > > > In failsoft mode there is not GENERAL RESOURCE profile checking, not > > GENERIC profiles in DATASET class. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > W dniu 25.11.2024 o 15:42, Seymour J Metz pisze: > >> "Why did you assume the profiles were discrete?" > >> > >> Because you mentioned WTORs. > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> עַם יִשְׂרָאֵל חַי > >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > >> > >> > >> > >> ________________________________________ > >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Radoslaw Skorupka <00000471ebeac275-dmarc- > requ...@listserv.ua.edu> > >> Sent: Monday, November 25, 2024 7:47 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > >> > >> External Message: Use Caution > >> > >> > >> Why did you assume the profiles were discrete? > >> Actually no profile was discrete. > >> I did it over 20 years ago, however I have never used discrete DATASET > >> profiles. > >> Rather the above it would be better to discuss about tiny ISPF setup - I > >> mean minimum set of libraries in concatenations, etc. > >> Instead of that I chose to prepare recovery using tech system. > >> > >> Oh, BTW: The above exercise was done because I *did* loose RACF dbs. > >> *Both*. It wasn't my fault, however someone ran IRRMIN NEW over > existing > >> dbs. > >> Fortunately I had UT200 copies so it was enough to logon from another > >> system and recover datasets. > >> (to be clear: UADS exercise was performed later, just for > >> learning/evaluation.) > >> > >> Again, my opinion: tech system + disk copies of RACF db is much better > >> than UADS. It is easier, more convenient, more flexible, less error-prone. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> W dniu 25.11.2024 o 13:19, Seymour J Metz pisze: > >>> 2. Why blame UADS instead of blaming discrete dataset profiles? > >>> Generic profiles have been around for decades. > >>> > >>> I used to have an un privileged userid for testing and a privileged > >>> userid for > things that required it. I too see nothing wrong with it. > >>> > >>> -- > >>> Shmuel (Seymour J.) Metz > >>> http://mason.gmu.edu/~smetz3 > >>> עַם יִשְׂרָאֵל חַי > >>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > >>> > >>> > >>> > >>> ________________________________________ > >>> From: IBM Mainframe Discussion List<IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Radoslaw Skorupka<00000471ebeac275-dmarc- > requ...@listserv.ua.edu> > >>> Sent: Monday, November 25, 2024 5:53 AM > >>> To:IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > >>> > >>> External Message: Use Caution > >>> > >>> > >>> My $0.02 > >>> > >>> (off-topic) > >>> 1. UADS is not needed today. > >>> 2. UADS is *bad* way to proceed when "security server fails to come up". > >>> There are much better ways, like backup copy of RACF db and some tech > >>> system. Once upon a time I tried to logon in failsafe mode. Access to > >>> every dataset means WTOR. Approx 100 WTORs to get IPSF first screen. > >>> > >>> (on-topic) > >>> 3. In sysplex multiple logons to TSO are possible, one logon per z/OS > >>> image. > >>> 4. The above is not black magic, however it require some simple changes > >>> in ISPF configuration. > >>> 5. I don't know about documentation, however it is well described on > >>> some SHARE presentations available on Internet. > >>> 6. The above is quite easy to test in some environment, in case of > >>> mistake the backout is also easy. > >>> 7. There are some (old, I suppose) "custom" ways to do it, however I > >>> would not recommend it. There is no reason to make live harder. > >>> > >>> (again off-topic) > >>> 8. From security point of view it is unacceptable to have single userid > >>> used by several persons. However it is nothing wrong in having multiple > >>> userids per person - each userid is owned by *one* person. And of course > >>> sometimes it is convenient and justified to have more than one userid. > >>> > >>> -- > >>> Radoslaw Skorupka > >>> Lodz, Poland > >>> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
