Oh, my. Given the fact that many of our users cannot remember a
single RACF logon id, assigning them multiple would cause chaos.
Seriously???? Well ok... Perhaps if you numbered the UIDs, things
would be easier. Mine are DBCOLE1 thru 9. I may be 67 years old now,
but I don't yet have trouble remembering this.
And is against company policy.
Your company should consider changing its policy. There is no
significant per-userid overhead, especially when you stop to consider
that for the most part, even though a user might have nine sessions
up and running, he still generally does only one thing at a time...
That leaves 8 sessions mostly idle at any given point in time.
Of course, there may be other reasons for such a company policy, but
for me, having multiple sessions improves my productivity. Are
policies against multiple userids really worth the productivity
limitations they create?
Dave
At 1/29/2014 09:31 AM, John McKown wrote:
Oh, my. Given the fact that many of our users cannot remember a single RACF
logon id, assigning them multiple would cause chaos. And is against company
policy. We really need to implement EIM and an SSO solution (zero cost with
no overhead, of course) so that Windows people can access z/OS (TSO, ftp,
and CICS) without needing to do another logon. Of course, this won't solve
all the id problems because we have literally had people forget their name
(Oh? I said kathy.mulligan? It should be cathy.mulligan! But everybody
calls me "cat".)
On Wed, Jan 29, 2014 at 8:22 AM, David Cole <dbc...@colesoft.com> wrote:
> Hmmmmm... I think most of the prior respondents to this thread may be a
> bit too much on point...
>
> In my own work, I routinely auto-logon as many as nine separate TSO
> sessions (all onto the same LPAR of course, but each using a unique
> userid). I then make them "appear" to be the same userid by way of a
> PROFILE PREFIX(&SYSUID) command that is automatically issued (from a logon
> CLIST) at logon time. This causes all of the logons to access the same,
> common set of datasets and libraries.
>
> For security management purposes, all of these userids are collected
> together into a single RACF group so that permissions assigned to the group
> are automatically propagated to the individual userids.
>
> IHTH,
> Dave Cole
>
>
>
>
>
> At 1/28/2014 09:15 PM, Govind Chettiar wrote:
>> A contractor who joined our team said that in his previous place of
>> employment he could have multiple TSO sessions each of which used the same
>> userid and password, so he used to have multiple instances of his TN3270
>> emulator running and a different TSO session in each.
>>
>> I am curious to know how this is possible...can anyone explain?
>>
>> My b/g is Cobol application development, so not versed with VTAM etc, so
>> bear with me!
>>
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com
>
> Home page: www.colesoft.com
> Facebook: www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com
Home page: www.colesoft.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
