My comments are sprinkled below, some of this information is out of date.
Regards,
Tom Conley
On 8/14/2014 4:10 PM, Elardus Engelbrecht wrote:
David Platt wrote:
We are running z/OS 1.13 with ACF2 and plan on implementing z/OS V2R1 in the
2nd Qtr of 2015. We also have a few users that use RDz. We have successfully
implemented the changes as described for Multiple TSO SIGNON on the Same MAS or
SYSPLEX, but on different LPARs. We have chosen to allocate unique TSO
datasets to each LPAR and avoid sharing.
Good. I hope you also changed GRSRNL member and perhaps ISPF exit nr 16 too. I
hope you have reviewed Mark Zelden's web page about this using same TSO
sessions with the same user id across the SysPlex.
The only change to GRSRNLxx is to completely remove any reference to
SYSIKJUA (in the past you had to play games with it). Also, exit 16 is
no longer necessary, just use the Temporary Dataset Additional Qualifier
in the ISPF Configuration Dialog. See my Configuring ISPF for Fun and
Profit presentation and my article on multiple logon (search on SYSIKJUA
to get the hit for that one).
Several users have multiple USER Ids, and we have been asked to eliminate the
duplicate IDs per user. Several users are saying they need, at least, two TSO
sessions per LPAR.
They are right. Some of my users also have two [different] TSO ids. Two is
enough and practical anyways.
You should review the roles and logon procs of those ids. Perhaps you need to
connect them to the right groups or give access to resources.
Anyways, some utilities in TSO / ISPF cannot be shared unless you're going to
modify a lot of things, now and at every upgrades.
Agreed. While z/OSMF enabled multiple ISPF windows on the same system,
TSO has not been modified to support those facilities. Sounds like a
great requirement.
I'm looking for ways to implement multiple sessions, if there are any.
You'll have to figure a way to eliminate IKJ56425I and IKJ606I. AFAIK, it is
just not possible. If I remember correctly, it is about the name in the TSO
session address space and VTAM assignment of LU against a TSO name. VTAM can
handle multiple *LOGON*, but after successfull logon it can't handle a second
or more address space with the same name within a LPAR.
PS: I don't have sources about my statements in last paragraph.
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
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
