Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Mark Charles]

When is ISPPROF updated?:

o Immediately when a user makes a change.  YES




Thank you,

Mark Charles

eWorld Consultant

(780) 974-9129

Vacation:  Dec. 12, Jan. 4, Feb. 28


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, November 23, 2024 06:26
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

On Sat, 23 Nov 2024 07:45:56 -0700, Lizette Koehler wrote:

>There is a parm called LOGONHERE which allows multiple logins in any plex lpar 
>by the same ID
>
>We have been using this since 2012 without issue.
> .
When is ISPPROF updated?:

o Immediately when a user makes a change?

o When a user logs off?

o Only when a user logs off after making a change?

o Changes made on one LPAR do not affect other LPArRs?

o When a user invokes a utility to propagate changes?

o Etc.?

--
gil

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[dasdbill2]

I slightly misremembered Deniro's quote.  It should have been "If there's any 
doubt, there's no doubt."Sent from my Verizon, Samsung Galaxy smartphone
 Original message From: WILLIAM FAIRCHILD 
 Date: 11/25/24  1:28 PM  (GMT-05:00) To: IBM Mainframe 
Discussion List  Subject: Re: Logon to TSO+ISPF on 
multiple LPAR's at the same time? 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 FairchildColumbia, South 
CarolinaUSAAwareness is the precursor to change.> On 11/22/2024 6:14 PM EST Don 
Leahy  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 
> 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 
 on behalf> > of Don Leahy > > 
Reply-To: IBM Mainframe Discussion List > > Date: 
Friday, November 22, 2024 at 5:01 PM> > To: "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 
<> > 042bfe9c879d-dmarc-requ...@listserv.ua.edu > 
042bfe9c879d-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. .ISPF.ISPPROF,> > >> > 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Dave Gibney]

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  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  on
> behalf of Radoslaw Skorupka <0471ebeac275-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  on
> behalf of Radoslaw Skorupka <0471ebeac275-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  on
> behalf of Radoslaw Skorupka <0471ebeac275-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, 

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

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  on behalf of 
Radoslaw Skorupka <0471ebeac275-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  on behalf of 
> Radoslaw Skorupka <0471ebeac275-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  on behalf of 
>> Radoslaw Skorupka <0471ebeac275-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 on behalf of 
>>> Radoslaw Skorupka<0471ebeac275-dmarc-requ...@listserv.ua.edu>
>>> Sent: Monday, November 25, 2024 5:53 AM
>>

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Radoslaw Skorupka]

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  on behalf of Radoslaw 
Skorupka <0471ebeac275-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  on behalf of Radoslaw 
Skorupka <0471ebeac275-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 on behalf of Radoslaw 
Skorupka<0471ebeac275-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


--

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[WILLIAM FAIRCHILD]

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  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 
> 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  on behalf
> > of Don Leahy 
> > Reply-To: IBM Mainframe Discussion List 
> > Date: Friday, November 22, 2024 at 5:01 PM
> > To: "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 <
> > 042bfe9c879d-dmarc-requ...@listserv.ua.edu > 042bfe9c879d-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. .ISPF.ISPPROF,
> > >
> > 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

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  on behalf of 
Radoslaw Skorupka <0471ebeac275-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  on behalf of 
> Radoslaw Skorupka <0471ebeac275-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 on behalf of 
>> Radoslaw Skorupka<0471ebeac275-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 IB

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Wendell Lovewell]

I'm not familiar with most of the techniques mentioned so far.  But I'm 
surprised no one has mentioned the SHRPROF option on the ISPF command, or the 
SHRPROF command to configure it. 

I start my ISPF session with ISPF TEST SHRPROF, and I can log on to different 
systems in my SYSPLEX, sharing the same ISPPROF.  (TEST is because I sometimes 
develop ISPF applications--it is not associated with the SHRPROF option.) 

There is also the ISPF command (once you are logged on) named SHRPROF, 'tho 
until I searched for the option I didn't know about the command. 

HTH, 
Wendell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Radoslaw Skorupka]

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  on behalf of Radoslaw 
Skorupka <0471ebeac275-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 on behalf of Radoslaw 
Skorupka<0471ebeac275-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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

"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  on behalf of 
Radoslaw Skorupka <0471ebeac275-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 on behalf of 
> Radoslaw Skorupka<0471ebeac275-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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Paul Gilmartin]

On Mon, 25 Nov 2024 11:53:53 +0100, Radoslaw Skorupka  wrote:

>My $0.02
>
>(off-topic)
> .


-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Radoslaw Skorupka]

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 on behalf of Radoslaw 
Skorupka<0471ebeac275-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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

 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  on behalf of 
Radoslaw Skorupka <0471ebeac275-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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Jack Zukt]

Hi,

A lifetime ago, or at least on another century, we used ISPF exit ISREX16
to overcome this situation for ISPF work files. I think it might have been
on an OS/390 2.6. I really have no idea if that is still needed, but the
exit is still active on those systems, now running z/OS 2.5.
Regards
Jack


On Mon, 25 Nov 2024 at 11:01, David Spiegel <
0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

> Hi Radek,
> You said: "... it is convenient and justified to have more than one
> userid ..."
> +1
>
> Regards,
> David
>
> On 11/25/2024 05:53, Radoslaw Skorupka wrote:
> > 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.
> >
>
> --
> 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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[David Spiegel]

Hi Radek,
You said: "... it is convenient and justified to have more than one 
userid ..."

+1

Regards,
David

On 11/25/2024 05:53, Radoslaw Skorupka wrote:

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.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Radoslaw Skorupka]

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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

Prefix is carried by SAF and updated only at LOGOFF.

-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Sunday, November 24, 2024 9:55 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


I am referring to the use of Prefix, (If I remember the name of
the field in PROFILE correctly).

In some tools and ISPF applications I have written/worked on, we
were having to make changes to that, and I wonder if this would
get reflected across all the LPARs as soon as it would be changed
--ISPF using CF structures?


Steve Thompson



On 11/24/2024 7:12 PM, Brian Westerman wrote:
> You don't do anything with the HLQ, it's the second level qualifier (or any 
> of the ones after the HLQ) that is affected when you want to log onto 
> multiple LPARs with the saem ID.
>
> For instance
>
> Production = BRIAN.PROD.ISPPROF
> TEST = BRIAN.TEST.ISPPROF
> Sandbox = BRIAN.SBOX.ISPPROF
>
> All of them are actually use the SYSNAME variable in the REXX exec or clist 
> that invokes ISPF when the user logs on, the tail part of mine is:
>
> "ALLOC FI(ISPLLIB) SH REU DS("XX
>
> ATTR="LRECL(80)BLKSIZE(0)RECFM(F,B)"
>
> PROF="'"USERID()"."MVSVAR("SYSNAME")".ISPPROF'"  <-- note the SYSNAME 
> variable
>
> IF SYSDSN(PROF)\="OK" THEN
>
>"ALLOC DIR(50)SP(5,5)CYL DSORG(PO) DS("PROF")"ATTR
>
>"ALLOC FI(ISPPROF) SH REU DS("PROF
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Regards,
Steve Thompson

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steve Thompson]

I am referring to the use of Prefix, (If I remember the name of 
the field in PROFILE correctly).


In some tools and ISPF applications I have written/worked on, we 
were having to make changes to that, and I wonder if this would 
get reflected across all the LPARs as soon as it would be changed 
--ISPF using CF structures?



Steve Thompson



On 11/24/2024 7:12 PM, Brian Westerman wrote:

You don't do anything with the HLQ, it's the second level qualifier (or any of 
the ones after the HLQ) that is affected when you want to log onto multiple 
LPARs with the saem ID.

For instance

Production = BRIAN.PROD.ISPPROF
TEST = BRIAN.TEST.ISPPROF
Sandbox = BRIAN.SBOX.ISPPROF

All of them are actually use the SYSNAME variable in the REXX exec or clist 
that invokes ISPF when the user logs on, the tail part of mine is:

"ALLOC FI(ISPLLIB) SH REU DS("XX

ATTR="LRECL(80)BLKSIZE(0)RECFM(F,B)"
   
PROF="'"USERID()"."MVSVAR("SYSNAME")".ISPPROF'"  <-- note the SYSNAME variable
  
IF SYSDSN(PROF)\="OK" THEN
  
   "ALLOC DIR(50)SP(5,5)CYL DSORG(PO) DS("PROF")"ATTR

   "ALLOC FI(ISPPROF) SH REU DS("PROF


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Don Leahy]

You might also need to review your ISPCFIG settings to confirm that the
LPAR name is included in some temporary file names used by ISPF.  (TSO
ISPCCONF)

On Sun, Nov 24, 2024 at 19:12 Brian Westerman <
06ba4ed225c9-dmarc-requ...@listserv.ua.edu> wrote:

> You don't do anything with the HLQ, it's the second level qualifier (or
> any of the ones after the HLQ) that is affected when you want to log onto
> multiple LPARs with the saem ID.
>
> For instance
>
> Production = BRIAN.PROD.ISPPROF
> TEST = BRIAN.TEST.ISPPROF
> Sandbox = BRIAN.SBOX.ISPPROF
>
> All of them are actually use the SYSNAME variable in the REXX exec or
> clist that invokes ISPF when the user logs on, the tail part of mine is:
>
> "ALLOC FI(ISPLLIB) SH REU DS("XX
>
> ATTR="LRECL(80)BLKSIZE(0)RECFM(F,B)"
>
> PROF="'"USERID()"."MVSVAR("SYSNAME")".ISPPROF'"  <-- note the SYSNAME
> variable
>
> IF SYSDSN(PROF)\="OK" THEN
>
>   "ALLOC DIR(50)SP(5,5)CYL DSORG(PO) DS("PROF")"ATTR
>
>   "ALLOC FI(ISPPROF) SH REU DS("PROF
>
> --
> 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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Brian Westerman]

You don't do anything with the HLQ, it's the second level qualifier (or any of 
the ones after the HLQ) that is affected when you want to log onto multiple 
LPARs with the saem ID.

For instance

Production = BRIAN.PROD.ISPPROF
TEST = BRIAN.TEST.ISPPROF
Sandbox = BRIAN.SBOX.ISPPROF

All of them are actually use the SYSNAME variable in the REXX exec or clist 
that invokes ISPF when the user logs on, the tail part of mine is:

"ALLOC FI(ISPLLIB) SH REU DS("XX 

   
ATTR="LRECL(80)BLKSIZE(0)RECFM(F,B)"
  
PROF="'"USERID()"."MVSVAR("SYSNAME")".ISPPROF'"  <-- note the SYSNAME 
variable
 
IF SYSDSN(PROF)\="OK" THEN
 
  "ALLOC DIR(50)SP(5,5)CYL DSORG(PO) DS("PROF")"ATTR
   
  "ALLOC FI(ISPPROF) SH REU DS("PROF

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steve Thompson]

I'm a bit confused. I think I have gotten lost in the postings. 
But something did get my attention:


If I have to change my profile's HLQ, and I'm running REXX in 
LPAR1 while also logged on on LPARs2-3, Won't that change done 
within that REXX affect the PROFILE in the other LPARs with their 
next read of the profile data? -- UNLESS those profile data sets 
are unique? This kind of thing really makes the profile have to 
be unique on each LPAR to avoid issues like this. Unless I'm 
missing something.


Steve Thompson

On 11/23/2024 6:19 PM, David Spiegel wrote:

Hi Gil,
You said: "...It is no better than assigning multiple User IDs. 
..." What's wrong with one person having more than one userid? 
Sometimes it is necessary. For example, one userid is running a 
TSO Command and the other is setting/changing system trace 
options or looking at dumps. At one of my jobs, the developers 
get 5 userids. Regards, David

On 11/22/2024 16:09, Paul Gilmartin 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. 
.ISPF.ISPPROF,


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 
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.






--
Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[David Spiegel]

Hi Gil,
You said: "...It is no better than assigning multiple User IDs. ..." 
What's wrong with one person having more than one userid? Sometimes it 
is necessary. For example, one userid is running a TSO Command and the 
other is setting/changing system trace options or looking at dumps. At 
one of my jobs, the developers get 5 userids. Regards, David

On 11/22/2024 16:09, Paul Gilmartin 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. .ISPF.ISPPROF,


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 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.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[David Spiegel]

Hi Gil,
You said "...Many (but not all) users would find this unacceptable. ..."
I can easily argue this point. Many users would find it more convenient 
to have separate ISPF environments for SandBox/Test/Dev/QA/Prod 
(especially SysProgs).


Regards,
David

On 11/22/2024 16:09, Paul Gilmartin 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. .ISPF.ISPPROF,


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 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.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Paul Gilmartin]

On Sat, 23 Nov 2024 07:45:56 -0700, Lizette Koehler wrote:

>There is a parm called LOGONHERE which allows multiple logins in any plex lpar 
>by the same ID
>
>We have been using this since 2012 without issue.
> .
When is ISPPROF updated?:

o Immediately when a user makes a change?

o When a user logs off?

o Only when a user logs off after making a change?

o Changes made on one LPAR do not affect other LPArRs?

o When a user invokes a utility to propagate changes?

o Etc.?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Lizette Koehler]

There is a parm called LOGONHERE which allows multiple logins in any plex lpar 
by the same ID

We have been using this since 2012 without issue.

Lizette

Sent from EarthLink Mobile mail

On 11/23/24, 00:58, Brian Westerman 
<06ba4ed225c9-dmarc-requ...@listserv.ua.edu> wrote:

That's ridiculous, I do it all the time, and so do hundreds of other sites. 
Lionel Dyck had some directions previously, but there are some on the CBT tape 
as well. It's just a matter of making sure that your personal ISPF datasets 
don't have the same name. Typically you insert the LPAR name in the dataset 
names for them so that you don't try to allocate the same ones.

All other datasets are fine to share, it's just the personal ISPF ones 
(ISPPROF, etc. that you have to worry about). It should take you jsut a few 
minutes to set it up.

Brian

--

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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Brian Westerman]

That's ridiculous, I do it all the time, and so do hundreds of other sites.  
Lionel Dyck had some directions previously, but there are some on the CBT tape 
as well.  It's just a matter of making sure that your personal ISPF datasets 
don't have the same name.  Typically you insert the LPAR name in the dataset 
names for them so that you don't try to allocate the same ones.

All other datasets are fine to share, it's just the personal ISPF ones 
(ISPPROF, etc. that you have to worry about).  It should take you jsut a few 
minutes to set it up.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Don Leahy]

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 
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  on behalf
> of Don Leahy 
> Reply-To: IBM Mainframe Discussion List 
> Date: Friday, November 22, 2024 at 5:01 PM
> To: "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 <
> 042bfe9c879d-dmarc-requ...@listserv.ua.edu 042bfe9c879d-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. .ISPF.ISPPROF,
> >
> 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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Schmitt, Michael]

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  on behalf of Don 
Leahy 
Reply-To: IBM Mainframe Discussion List 
Date: Friday, November 22, 2024 at 5:01 PM
To: "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 <
042bfe9c879d-dmarc-requ...@listserv.ua.edu<mailto:042bfe9c879d-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. .ISPF.ISPPROF,
>
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Don Leahy]

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 <
042bfe9c879d-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. .ISPF.ISPPROF,
> >
> 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  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 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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Paul Gilmartin]

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. .ISPF.ISPPROF,
> 
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  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 with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Seymour J Metz]

You have to configure so that, e.g., ISPF data sets, have unique names. It used 
to be well documented.

-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, November 22, 2024 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Logon to TSO+ISPF on multiple LPAR's at the same time?

External Message: Use Caution


I was certain that there were (somewhere) instructions on how to enable a user 
to logon to TSO+ISPF on more than one LPAR at the same time with the same 
USERID, but I cannot find such instructions so far.

TIA for any doc url you can provide.

Peter

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steve Beaver]

All your ISPF datasets will become a problem





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steely.Mark
Sent: Friday, November 22, 2024 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

I do not have UADS here and do not use the specified exit.

The only modification I made was to the PROFILE, where I added the &SYSNAME
esoteric.

The major change involves the parmlib member GRSRNL00. Specifically, the
following rule must be updated:

RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIKJUA) RNAME()

The RNAME specifies an ID because we restrict this action to certain
individuals.
If you do not wait it restricted remove the RNAME.

When you add this dynamically, it generates a WTO to propagate the change
across all LPARs.
Afterward, you must update this rule on all LPARs.

Please note, the GRSRNL00 member must remain consistent across all LPARs;
otherwise, the IPL process will fail.

Additionally, I believe the TSO ISPCCONF utility includes a PROFILE_SHARING
value that may require updating to enable profile sharing.

I do not utilize profile sharing, as I maintain separate profiles for each
LPAR.

Hope this helps.

Thank You


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Paul Gilmartin
Sent: Friday, November 22, 2024 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

 !

CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person?
Were you expecting this email? If not, report it using the Report Phishing
Button!

On Fri, 22 Nov 2024 13:19:02 -0600, Lionel B Dyck wrote:

>See
>https://www.i/
>bm.com%2Fdocs%2Fen%2Fzos%2F3.1.0%3Ftopic%3Dlogons-duplicate&data=05%7C0
>2%7CSteely.Mark%40ACE.AAA.COM%7C82760b5bb3e648a84e7308dd0b2c6975%7Cd5f6
>18ff295149048f7e999c2dd97ab2%7C0%7C0%7C638679007564629839%7CUnknown%7CT
>WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
>IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oA9ds%2FmdV17x0UHxI
>QxZ37Pcxl8BaFg0f7uGPpYOcUc%3D&reserved=0
>
Is UADS still a thing?  I'm surprise.  I thought it was replaced by RACF
long ago.

--
gil

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[David Spiegel]

All? ... No, just the //ISPPROF which can be fixed by including the LPAR 
name as part of the DSNAME. E.g. .ISPF.ISPPROF,




On 11/22/2024 15:12, Steve Beaver wrote:

All your ISPF datasets will become a problem





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steely.Mark
Sent: Friday, November 22, 2024 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

I do not have UADS here and do not use the specified exit.

The only modification I made was to the PROFILE, where I added the &SYSNAME
esoteric.

The major change involves the parmlib member GRSRNL00. Specifically, the
following rule must be updated:

RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIKJUA) RNAME()

The RNAME specifies an ID because we restrict this action to certain
individuals.
If you do not wait it restricted remove the RNAME.

When you add this dynamically, it generates a WTO to propagate the change
across all LPARs.
Afterward, you must update this rule on all LPARs.

Please note, the GRSRNL00 member must remain consistent across all LPARs;
otherwise, the IPL process will fail.

Additionally, I believe the TSO ISPCCONF utility includes a PROFILE_SHARING
value that may require updating to enable profile sharing.

I do not utilize profile sharing, as I maintain separate profiles for each
LPAR.

Hope this helps.

Thank You


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Paul Gilmartin
Sent: Friday, November 22, 2024 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

  !

CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person?
Were you expecting this email? If not, report it using the Report Phishing
Button!

On Fri, 22 Nov 2024 13:19:02 -0600, Lionel B Dyck wrote:


See
https://www.i/
bm.com%2Fdocs%2Fen%2Fzos%2F3.1.0%3Ftopic%3Dlogons-duplicate&data=05%7C0
2%7CSteely.Mark%40ACE.AAA.COM%7C82760b5bb3e648a84e7308dd0b2c6975%7Cd5f6
18ff295149048f7e999c2dd97ab2%7C0%7C0%7C638679007564629839%7CUnknown%7CT
WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oA9ds%2FmdV17x0UHxI
QxZ37Pcxl8BaFg0f7uGPpYOcUc%3D&reserved=0


Is UADS still a thing?  I'm surprise.  I thought it was replaced by RACF
long ago.

--
gil

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steely.Mark]

I do not have UADS here and do not use the specified exit.

The only modification I made was to the PROFILE, where I added the &SYSNAME 
esoteric.

The major change involves the parmlib member GRSRNL00. Specifically, the 
following rule must be updated:

RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIKJUA) RNAME()

The RNAME specifies an ID because we restrict this action to certain 
individuals.
If you do not wait it restricted remove the RNAME.

When you add this dynamically, it generates a WTO to propagate the change 
across all LPARs.
Afterward, you must update this rule on all LPARs.

Please note, the GRSRNL00 member must remain consistent across all LPARs; 
otherwise, the IPL process will fail.

Additionally, I believe the TSO ISPCCONF utility includes a PROFILE_SHARING 
value that may require updating to enable profile sharing.

I do not utilize profile sharing, as I maintain separate profiles for each LPAR.

Hope this helps.

Thank You


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, November 22, 2024 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

 !

CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

On Fri, 22 Nov 2024 13:19:02 -0600, Lionel B Dyck wrote:

>See
>https://www.i/
>bm.com%2Fdocs%2Fen%2Fzos%2F3.1.0%3Ftopic%3Dlogons-duplicate&data=05%7C0
>2%7CSteely.Mark%40ACE.AAA.COM%7C82760b5bb3e648a84e7308dd0b2c6975%7Cd5f6
>18ff295149048f7e999c2dd97ab2%7C0%7C0%7C638679007564629839%7CUnknown%7CT
>WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
>IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oA9ds%2FmdV17x0UHxI
>QxZ37Pcxl8BaFg0f7uGPpYOcUc%3D&reserved=0
>
Is UADS still a thing?  I'm surprise.  I thought it was replaced by RACF long 
ago.

--
gil

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Mike Schwab]

Its a backup in case your security server fails to come up.

On Fri, Nov 22, 2024 at 1:32 PM Paul Gilmartin
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Fri, 22 Nov 2024 13:19:02 -0600, Lionel B Dyck wrote:
>
> >See https://www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate
> >
> Is UADS still a thing?  I'm surprise.  I thought it was replaced by RACF long 
> ago.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Farley, Peter]

Thank you.

From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Friday, November 22, 2024 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?


See 
https://www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OvceWRY-6I01L8tpt_b7Q3S06yQ16amx3yXlNIlZUt7VGbJEzDZmZPxNOk43AZ4661LxmeyAVMq1a3wrhxXngkarGuUx8Ee51b4Zghd_$>



On Fri, Nov 22, 2024 at 1:16 PM Steely.Mark <

0708bf6ac9be-dmarc-requ...@listserv.ua.edu<mailto:0708bf6ac9be-dmarc-requ...@listserv.ua.edu>>
 wrote:



> Yes - it can be done - because at my work I am able to logon to all the

> LPAR's at the same time with one ID.

>

> -Original Message-

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf

> Of Steve Beaver

> Sent: Friday, November 22, 2024 1:11 PM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

>

> The answer is NO

>

> -Original Message-

> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On

> Behalf Of Farley, Peter

> Sent: Friday, November 22, 2024 1:09 PM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: Logon to TSO+ISPF on multiple LPAR's at the same time?

>

> I was certain that there were (somewhere) instructions on how to enable a

> user to logon to TSO+ISPF on more than one LPAR at the same time with the

> same USERID, but I cannot find such instructions so far.

>

> TIA for any doc url you can provide.

>

> Peter

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Paul Gilmartin]

On Fri, 22 Nov 2024 13:19:02 -0600, Lionel B Dyck wrote:

>See https://www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate
>
Is UADS still a thing?  I'm surprise.  I thought it was replaced by RACF long 
ago.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Lionel B Dyck]

See https://www.ibm.com/docs/en/zos/3.1.0?topic=logons-duplicate

On Fri, Nov 22, 2024 at 1:16 PM Steely.Mark <
0708bf6ac9be-dmarc-requ...@listserv.ua.edu> wrote:

> Yes - it can be done - because at my work I am able to logon to all the
> LPAR's at the same time with one ID.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Steve Beaver
> Sent: Friday, November 22, 2024 1:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?
>
>  !
>
> CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this
> person? Were you expecting this email? If not, report it using the Report
> Phishing Button!
>
> The answer is NO
>
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter
> Sent: Friday, November 22, 2024 1:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Logon to TSO+ISPF on multiple LPAR's at the same time?
>
> I was certain that there were (somewhere) instructions on how to enable a
> user to logon to TSO+ISPF on more than one LPAR at the same time with the
> same USERID, but I cannot find such instructions so far.
>
> TIA for any doc url you can provide.
>
> Peter
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an
> authorized representative of the intended recipient, you are hereby
> notified that any dissemination of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately by e-mail and delete the message and any attachments from
> your system.
>
> --
> 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
>


-- 
Lionel B. Dyck <><
Website:https://github.com/lbdyck

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steely.Mark]

Yes - it can be done - because at my work I am able to logon to all the LPAR's 
at the same time with one ID. 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Friday, November 22, 2024 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

 !

CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

The answer is NO




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter
Sent: Friday, November 22, 2024 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Logon to TSO+ISPF on multiple LPAR's at the same time?

I was certain that there were (somewhere) instructions on how to enable a user 
to logon to TSO+ISPF on more than one LPAR at the same time with the same 
USERID, but I cannot find such instructions so far.

TIA for any doc url you can provide.

Peter

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized 
representative of the intended recipient, you are hereby notified that any 
dissemination of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by e-mail 
and delete the message and any attachments from your system.

--
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

Re: Logon to TSO+ISPF on multiple LPAR's at the same time?

[Steve Beaver]

The answer is NO




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter
Sent: Friday, November 22, 2024 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Logon to TSO+ISPF on multiple LPAR's at the same time?

I was certain that there were (somewhere) instructions on how to enable a
user to logon to TSO+ISPF on more than one LPAR at the same time with the
same USERID, but I cannot find such instructions so far.

TIA for any doc url you can provide.

Peter

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.

--
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