Cross contamination across various profle pools is a common occurrence at our shop where the locally developed tools failed to use a distinct APPLID. I was one of the offenders until I learned better.
On Fri, Nov 22, 2024 at 18:06 Schmitt, Michael <michael.schm...@dxc.com> wrote: > Our system allows multiple logins with profile sharing, but I never do it. > I don’t trust it. Even if every IBM application works, and even if every > third-party vendor application works, I don’t trust that our home-grown > applications would work. I think they’re making assumptions that the TSO id > = job name = unique name at this time. For example, it is safe to delete > and reallocate a data set userid.SOME.THING. > > I don’t even trust that the applications I wrote and maintain would work. > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Don Leahy <don.le...@leacom.ca> > Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > Date: Friday, November 22, 2024 at 5:01 PM > To: "IBM-MAIN@LISTSERV.UA.EDU" <IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time? > > Yes, and it’s not that difficult. You can either use ISPF profile sharing > or use a separate ISPF profile data set on each LPAR. I have done it both > ways. > > On Fri, Nov 22, 2024 at 16:09 Paul Gilmartin < > 0000042bfe9c879d-dmarc-requ...@listserv.ua.edu<mailto: > 0000042bfe9c879d-dmarc-requ...@listserv.ua.edu>> wrote: > > On Fri, 22 Nov 2024 15:18:36 -0500, David Spiegel wrote: > > >All? ... No, just the //ISPPROF which can be fixed by including the LPAR > >name as part of the DSNAME. E.g. <userid>.ISPF.ISPPROF,<lpar-name> > > > Ouch! Profile changes on any LPAR would not be effective on other > LPARs. Many (but not all) users would find this unacceptable. It is no > better than assigning multiple User IDs. > > But < > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F3.1.0%3Ftopic%3Dlogons-duplicate&data=05%7C02%7Cmichael.schmitt%40dxc.com%7Cd3d3da1b33424f7e657208dd0b498967%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C638679132662443719%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dL9Bbguv%2FbLtlf%2Fg0rd0LuraoUa4CY5BRqs0DQGg0cU%3D&reserved=0 > ><https://www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate> says: > ISPF profile sharing or changes to default ISPF data set names > might be needed to avoid errors in ISPF with multiple logons. > See z/OS ISPF Planning and Customizing for more details about > configuring ISPF to support multiple logons. > > "profile sharing" > > But the referenced document is an abstract containing > a circular reference. I'll submit a Feedback. > > -- > gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu<mailto: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<mailto: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
