I though this note was in my Newsletters, but it was buried in
the ADOC30 member that documents the SMF 30 fields. Alan told
me his story years ago:
ENQTIME NUM 8 DATETIME21.2 TSO LOGON*ENQUEUE ON UADS*TIME STAMP
TSO only. Time when LOGON process enqueues on the USERIDs member of
the STS1.UADS data set (containing user attributes). This time can
been used to calculate how long it takes to get Logged on TSO, using
LOGONTM=ENQTIME-READTIME, because the ENQTIME is the final event just
before the user's session becomes READY. This field exists but is
missing in TYPE30_V, TYPE30_4, and TYPE30_6 datasets, existing only
in the TYPE30_1 and TYPE30_5 job level records.
IBM'S ALAN SHEARER WAS A PRIME DEVELOPER OF TSO (AND LATER MVS).
The ENQUEUE on the SYS1.UADS was added to TSO on the final evening
before TSO was sent to PID for shipment. Alan had been conducting
final product tests in the lab from a TSO terminal, and took a
break. He returned to the lab, and forgetting that he was already
logged on at one terminal, logged on again from a different
terminal, but when he issued TSO commands, he received no output!
He was mystified until an adjacent tester commented "you're sure
getting a lot of messages at this other terminal where you are still
logged on!" Only then did Alan realize that TSO had no protection
for simultaneous sessions, and added the exclusive ENQUE on USERID
member to ensure only one session per USERID!
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of John McKown
Sent: Wednesday, January 29, 2014 3:55 PM
To: [email protected]
Subject: Re: multiple TSO Sessions (try this)
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 particular
session. Back in the MVT days, the CANCEL command did not have a way to direct
the CANCEL to a given region (as the A= does to a given address space today).
So if you had an id signed on 3 times with only
1 of them "having a problem", then a CANCEL U=thisid would cancel all 3
sessions. The same happened with started tasks and batch jobs. Oh, and I think
there was also a problem with the TIOC sending command output to the wrong
terminal. I.e. enter the LISTALC command on terminal#1 and the results might go
to terminal#2 instead. But I'm real vague on that last one.
This is likely not a problem in today's environment. But IBM is deprecating the
use of interactive TSO for using PCs interacting with z/OS using RD/z.
Why? Likely because it is more powerful and much more profitable. Fixing TSO is
probably like trying to build a road through a mine field of unexploded
ordinance.
On Wed, Jan 29, 2014 at 3:44 PM, Frank Swarbrick
<[email protected]>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?
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] 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
[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
