In 00ad01cf67fa$93d2bba0$bb7832e0$@soundsoftware.us, on 05/04/2014
at 05:40 PM, Duffy Nightingale du...@soundsoftware.us said:
I am a software developer and I use two TSO sessions. One on each
screen.
You can have multiple screens with a single userid. BTDT,GTTS.
--
Shmuel (Seymour
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Govind Chettiar
Sent: Saturday, February 01, 2014 5:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: multiple TSO Sessions (try this)
Sorry...When I click the reply icon all I see is a blank window. Some
On Sat, 1 Feb 2014 07:57:58 -0600, Govind Chettiar wrote:
Sorry...When I click the reply icon all I see is a blank window. Some
listservs have a reply with quote option which I don't see here and I assumed
that the prior messages are appended to my post.
I assume you are using the web
Sorry...When I click the reply icon all I see is a blank window. Some
listservs have a reply with quote option which I don't see here and I assumed
that the prior messages are appended to my post. I didn't explicitly delete or
eviscerate anything...
Anyway I was responding to Ted MacNeil's
I would respectfully disagree with this somewhat blanket statement. Many is
the time I'd have liked my ISPF Editor session in one window and the compiler
output in another so I can fix the syntax errors etc easily w/o having to F2
back and forth all the time. This is just one example.
Govind,
It would be helpful to know what somewhat blanket statement you are
disagreeing with.
For a thread like this one, to which many people have made motley
contributions, some [but not too much] context is necessary. Trimming
is good; evisceration is bad.
John Gilmore, Ashland, MA 01721 -
On Fri, 31 Jan 2014 06:39:47 -0600, Govind Chettiar wrote:
I would respectfully disagree with this somewhat blanket statement. ...
this? Please cite.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Discussion List
Subject: Re: multiple TSO Sessions (try this)
Sent: 31 Jan 2014 07:39
I would respectfully disagree with this somewhat blanket statement. Many is
the time I'd have liked my ISPF Editor session in one window and the compiler
output in another so I can fix the syntax errors etc easily w/o
You're not even getting IKJ56425I? You must have setup your system to allow
that.
No to both. At least not that I know of - this is an ADCD system. I do get
IKJ56425I when I attempt to logon a second time from a terminal emulator.
Note that the other 10 sessions do not have a VTAM ACB in the
Barbara Nitz wrote:
You're not even getting IKJ56425I? You must have setup your system to allow
that.
No to both. At least not that I know of - this is an ADCD system.
Ok.
Note that the other 10 sessions do not have a VTAM ACB in the PROCSTEP (and
don't count against that limit). And also
In article 20140130073546.4d7c503f89f322b8965a4...@gmx.net you wrote:
Is there some actual technical reason why TSO cannot be made to allow one
user ID to log in multiple times to TSO within a single LPAR?
Who says TSO does not allow one userid with several logins within a single
apar?
You should bump the split screens up to 32. Much more impressive. :)
I bite. How do I do that?
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
Change ISPCFIGU. Use the command ISPCCONF. IIRC the default number of split
screens is 8.
Bob Shannon
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
Change ISPCFIGU. Use the command ISPCCONF. IIRC the default number of split
screens is 8.
Thanks. Will do that, just to astonish my colleagues. :-) Yes, the default is 8.
Barbara
--
For IBM-MAIN subscribe / signoff /
: Re: multiple TSO Sessions (try this)
Change ISPCFIGU. Use the command ISPCCONF. IIRC the default number of split
screens is 8.
Thanks. Will do that, just to astonish my colleagues. :-) Yes, the default is 8.
Barbara
On Thu, 30 Jan 2014 01:21:19 -0600, Elardus Engelbrecht wrote:
Barbara Nitz wrote:
We only have one lpar (one system), and I am now logged in 11 times with the
same TSO userid. We have made sure that each of those TSO sessions has their
own ISPF profile data set. And each session can have up
:30 PM
Subject:Accountability (was: multiple TSO Sessions (try this))
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Ted MacNEIL wrote:
Unique mapping of userid to person is a valid issue.
You must be accountable for what you do.
Sharing of ids negates
jo.skip.robin...@sce.com
From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 01/29/2014 10:30 PM
Subject:Accountability (was: multiple TSO Sessions (try this))
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Ted
, 2014 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accountability (was: multiple TSO Sessions (try this))
There was a time when I promoted (at least) two userids for system support
folks. SLED DASD was far less reliable than today's virtual arrays, It was
a dreadfully monotonous occurrence
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Skip Robinson
Sent: Thursday, January 30, 2014 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accountability (was: multiple TSO Sessions (try this))
There was a time when I promoted (at least) two userids for system support
folks. SLED DASD was far
:35 PM
Subject: Re: multiple TSO Sessions (try this)
Is there some actual technical reason why TSO cannot be made to allow one
user ID to log in multiple times to TSO within a single LPAR?
Who says TSO does not allow one userid with several logins within a single
apar?
JOBNAME StepName
On Thu, 30 Jan 2014 14:35:19 -0400, Clark Morris wrote:
On 30 Jan 2014 09:55:32 -0800, in bit.listserv.ibm-main you wrote:
Every single TSO user in my shop is assigned two ID's. No one has ever asked
for a third, but many people only use one of their assigned ID's. We have
never had an
On 1/29/2014 10:35 PM, nitz-...@gmx.net wrote:
Who says TSO does not allow one userid with several logins within a single apar?
JOBNAME StepName ProcStep JobIDOwnerC Pos DP Real PagingSIO CPU%
ASID ASIDX
BARBARA CEAPROCF TSU07563 BARBARAOUT FF 2105 0.00 0.00
What is CEA?
From: Ed Jaffe edja...@phoenixsoftware.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, January 30, 2014 2:07 PM
Subject: Re: multiple TSO Sessions (try this)
On 1/29/2014 10:35 PM, nitz-...@gmx.net wrote:
Who says TSO does not allow one userid
On Thu, Jan 30, 2014 at 3:33 PM, Frank Swarbrick
frank.swarbr...@yahoo.comwrote:
What is CEA?
Real name: z/OSMF, or z/OS System Management Facility . Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/izuzsh21
--
Wasn't there something about a PASCAL programmer knowing the
On Thu, 30 Jan 2014 13:07:45 -0800, Ed Jaffe wrote:
Of course, CEA is the great equalizer (subsequent to the enhancements
for Web ISPF). Thanks for posting this Barbara! :-)
I thought I was curious, so I searched the doc for CEA (publibz; 1.13;
I have no idea how I'd do this with Infocenter, or
On 1/30/2014 1:41 PM, John McKown wrote:
On Thu, Jan 30, 2014 at 3:33 PM, Frank Swarbrick
frank.swarbr...@yahoo.comwrote:
What is CEA?
Real name: z/OSMF, or z/OS System Management Facility . Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/izuzsh21
I'm pretty sure the
But I am fairly sure that, IN THIS CONTEXT, the CEA which was being
mentioned in the thread was not Common Event Adapter, which has _nothing_
to do with multiple TSO logons that I can see, but was referred to z/OSMF
and its ability to allow multiple TSO sessions for a single user. I guess
we will
Any SHARE presentations? I did search Boston proceedings but didn't turn up
any hits.
In a message dated 1/30/2014 4:11:11 P.M. Central Standard Time,
edja...@phoenixsoftware.com writes:
I'm pretty sure the Common Event Adapter (CEA) predates z/OSMF
On 1/30/2014 2:17 PM, John McKown wrote:
But I am fairly sure that, IN THIS CONTEXT, the CEA which was being
mentioned in the thread was not Common Event Adapter, which has _nothing_
to do with multiple TSO logons that I can see, but was referred to z/OSMF
and its ability to allow multiple TSO
But I am fairly sure that, IN THIS CONTEXT, the CEA which was being
mentioned in the thread was not Common Event Adapter, which has _nothing_
to do with multiple TSO logons that I can see, but was referred to z/OSMF
and its ability to allow multiple TSO sessions for a single user. I guess
Hm... 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
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,
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
On Wed, Jan 29, 2014 at 9:50 AM, David Cole dbc...@colesoft.com wrote:
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
On Wed, 29 Jan 2014 08:31:07 -0600, 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
Yup. We can't even get a group ID for some tech support purposes.
If the employee having
Certainly, I know nothing of the Wirth of nothing.
[;-)]
At 1/29/2014 10:56 AM, John McKown wrote:
Wasn't there something about a PASCAL programmer knowing the value
of everything and the Wirth of nothing?
Maranatha!
John McKown
Dave Cole
ColeSoft Marketing
414 Third Street, NE
I truly believe that one ID per person with the ability to sign on once per
LPAR (and share the same ISPPROF) is simpler to implement.
I don't believe that the typical user needs multiple userids to do their job.
-
-teD
300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!
On Wed, Jan 29, 2014 at 10:08 AM, Paul Gilmartin paulgboul...@aim.comwrote:
snip
IBM is the only vendor I know of that enforces such an archaic restriction,
at least with CMS and TSO. But it's getting better with Unix System
Services.
(I suspect not with VM/CMS Open Extensions.) It's time
On Wed, Jan 29, 2014 at 10:35 AM, Ted MacNEIL
tedmacn...@bell.blackberry.net wrote:
I truly believe that one ID per person with the ability to sign on once
per LPAR (and share the same ISPPROF) is simpler to implement.
I don't believe that the typical user needs multiple userids to do their
On 29 January 2014 11:35, Ted MacNEIL tedmacn...@bell.blackberry.net wrote:
I truly believe that one ID per person with the ability to sign on once per
LPAR (and share the same ISPPROF) is simpler to implement.
No doubt. But simpler to implement may not be at the top of everyone's list.
I
At 1/29/2014 11:35 AM, Ted MacNEIL wrote:
I truly believe that one ID per person with the ability to sign on
once per LPAR (and share the same ISPPROF) is simpler to implement.
Perhaps... I wouldn't know. I have only one LPAR here and little to
no bureaucracy. So implementing multiple userids
W dniu 2014-01-29 22:28, David Cole pisze:
[...]
I don't believe that the typical user needs multiple userids to do
their job.
Of course not. I'm sorry if I seemed to be limiting my suggestion to
implementation for all users. There are other options...
Just because the typical user might
Is there some actual technical reason why TSO cannot be made to allow one user
ID to log in multiple times to TSO within a single LPAR?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
As I recall, this dates back to the beginnings of TSO under MVT. As I
recall the story, the original (perhaps unreleased) version of TSO did
allow multiple signons to a single id. But there was some sort of problem
having to do with how to CANCEL a given session, or how to SEND a message
to a
W dniu 2014-01-29 22:44, Frank Swarbrick pisze:
Is there some actual technical reason why TSO cannot be made to allow one user
ID to log in multiple times to TSO within a single LPAR?
Except lack of IBM will to enhance it? I doubt it.
It's one of numerous oold requirements which are
USERID!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Wednesday, January 29, 2014 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: multiple TSO Sessions (try this)
As I recall, this dates back to the beginnings
On Wed, 29 Jan 2014 13:44:41 -0800, Frank Swarbrick wrote:
Is there some actual technical reason why TSO cannot be made to allow one user
ID to log in multiple times to TSO within a single LPAR?
Yes. Bad design.
The assumption that the user ID could be used as a handle for an
interactive TSO
Radoslaw has made the fundamental point.
Some few prohibitions are of course necessary, but the best course in
most of these situations is to ask oneself the question, Do I really
need to say no?, and the answer is usually no.
Still, the gratuitous prohibitions proliferate; and the
When I said I truly believe anything more than one userid was needed by a
typical user, I NEVER said I would attempt to deny extra ones.
I would just have to have a valid reason why.
-
-teD
300,000 Kilometres per Second
Not only is it a good idea!
It's the LAW!!!
At 1/29/2014 06:03 PM, Ted MacNEIL wrote:
When I said I truly believe anything more than one userid was needed
by a typical user, I NEVER said I would attempt to deny extra ones.
I would just have to have a valid reason why.
One thing I've learned in product design over the decades is, just
On 1/29/2014 1:28 PM, David Cole wrote:
At 1/29/2014 11:35 AM, Ted MacNEIL wrote:
I truly believe that one ID per person with the ability to sign on
once per LPAR (and share the same ISPPROF) is simpler to implement.
Perhaps... I wouldn't know. I have only one LPAR here and little to no
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Jaffe
Sent: Wednesday, January 29, 2014 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: multiple TSO Sessions (try this)
On 1/29/2014 1:28 PM, David Cole wrote:
At 1/29
IBM in its infinite design of TSO was a small (but maybe important
item).
When you logoff TSO updates sys1.uads with the additional information
(like CPU time used). Sharing uads might (probably?) corrupt the field.
Now the question is does it do the same with RACF (ie no uads) I do
not know
There may be (more or less reasonable) reasons for an installation to insist
on unique userid/person.
Unique mapping of userid to person is a valid issue.
You must be accountable for what you do.
Sharing of ids negates that.
Multiple ids must still be assigned to single people for the same
Ted MacNEIL wrote:
Unique mapping of userid to person is a valid issue.
You must be accountable for what you do.
Sharing of ids negates that.
Indeed. As an unpopular RACF guy, I have a battle just about this. :-)
Subsequent audit trails proved my and your point.
It is not about 'I must win', but
I agree to that, One TSO userid per user in the same LPAR at a time to
perform his or her task. I don't understand the the logic of having
multiple logon's of the same userid in the *same LPAR* at the same time.
What I experienced is that if a TSO userid is logged on with a LPAR, loggin
on the
Is there some actual technical reason why TSO cannot be made to allow one
user ID to log in multiple times to TSO within a single LPAR?
Who says TSO does not allow one userid with several logins within a single apar?
JOBNAME StepName ProcStep JobIDOwnerC Pos DP Real PagingSIO
Barbara Nitz wrote:
Who says TSO does not allow one userid with several logins within a single
apar?
You're not even getting IKJ56425I? You must have setup your system to allow
that.
We only have one lpar (one system), and I am now logged in 11 times with the
same TSO userid. We have made
59 matches
Mail list logo
