Re: to trust or not to trust? In one of his many crime boss movies, Robert D. Niro uttered this line of wise guy wisdom: "If there's no doubt, then there's doubt."
Bill Fairchild Columbia, South Carolina USA Awareness is the precursor to change. > On 11/22/2024 6:14 PM EST Don Leahy <[email protected]> wrote: > > > 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 <[email protected]> > 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 <[email protected]> on behalf > > of Don Leahy <[email protected]> > > Reply-To: IBM Mainframe Discussion List <[email protected]> > > Date: Friday, November 22, 2024 at 5:01 PM > > To: "[email protected]" <[email protected]> > > 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 < > > [email protected]<mailto: > > [email protected]>> 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 [email protected]<mailto:[email protected]> > > with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected]<mailto:[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
