Re: Multiple TSO logons (was: Patents, ...)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/13/2007
   at 02:03 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>Theology.  Dogma.  Simply to start doing it right, you must stop
>doing it wrong.  Somehow I feel a major culprit is VTAM

"I feel" is not a helpful engineering term.

>Get rid of VTAM; let TCP/IP connect directly to
>the TMP input/output data streams.

The chances are between slim and none, and Slim's out od town.
Further, that wouldn't solve the problem.

>Somehow this all works for batch EXEC PGM=IKJEFT01,

No it doesn't. Batch TMP doesn't require the VTIOC setup and batch TMP
doesn't solve the dataset ENQ issues. The former is generally not a
problem and the user handles the latter manually.

>which I am told is the same TMP. 

It is, although the alternate entry points are intended specifically
for batch.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Mark Zelden]

On Sat, 16 Jun 2007 22:55:54 +1000, Greg Price <[EMAIL PROTECTED]>
wrote:

>
>Warning: the way I did it makes no allowance for SYSPLEX or shared SPOOL
>(Didn't JES2 enforce unique TSU job ids in a MAS?  Was this ever changed?)

Yes.  The dup check was removed from JES2 in z/OS 1.4.  JES3 still hasn't 
removed the check - at least up though z/OS 1.8.  

I'm sure you know virtually everyone who used duplicate userids in a 
JES2 MAS prior to z/OS 1.4 used a usermod.  There is a CBT sample
where someone used EXIT 44 (converter) instead.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Chris Mason]

Tony

So in tune with Paul's verbal abuse, mixing metaphors, he should be casting 
his boulders in the direction of TSO, not VTAM since it would appear the TSO 
developers have been negligent in not keeping strictly to the published TCAM 
and VTAM APIs.


Apart from the minimal intervention "around the edges" which the exceptional 
function supplied by VTAM in order to have local (non-SNA) channel-attached 
3270 controllers (or their "look-alikes") appear to be type 0 secondary 
logical units which only incidentally use the 3270 data stream, VTAM has no 
interest in the *content* of the 3270 data stream. The "minimal 
intervention" extends only to a mapping and transformation of the first 
character in the data stream, the "write control character", to the "channel 
command word" and vice versa in order to ensure that the 3270 data stream is 
the same in all environments fore the benefit of the device-independent 
program.


Or something like that, it's a while since I looked at it but I know that 
whatever VTAM did can't have been one of your inhibitors.


Incidentally, did you ever take a look at the 3270<>Asynchronous ASCII 
protocol converters such as the 3708 or 7171?


Chris Mason

- Original Message - 
From: "Tony Harminc" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, June 15, 2007 3:30 AM
Subject: Re: Multiple TSO logons (was: Patents, ...)


On Wed, 13 Jun 2007 14:03:15 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]>

wrote:


Theology.  Dogma.  Simply to start doing it right, you must
stop doing it wrong.  Somehow I feel a major culprit is VTAM
because whenever this issue arises an expert starts spouting
VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
the TMP input/output data streams.


I've looked at this, and "it isn't pretty" doesn't even begin to describe
it. Unless IBM has severely modularized things since the last non-OCO
version of this stuff, it is full of hardcoded knowledge of not only VTAM
(and TCAM!) module names, but of their various quirky behaviours.

This is one of those situations where everyone agrees that it would be a
Good Thing to replace some part of the legacy stuff, but everyone 
disagrees

on just which parts are legacy junk, and which are the very core of the
architecture.

When I worked for Amdahl/Antares on Huron, we had complete control over 
the

applications that drove 3270 screens, and once all the real green-screens
had gone away, it began to make sense to consider designing our own new 
3270

protocol along with an emulator that would exploit it. But it never
happened, because there were just too many layers (CICS, VTAM, TSO, ...)
that all had to be fixed at exactly the same time.

Tony H.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Chris Mason]

Paul

Prejudice[1] is like a neglected slip, it sometimes shows to the acute 
embarrassment of the wearer.


There was not an iota of "VTAM jargon" present in the quoted post - but 
there were some very well-known CICS abbreviations. Were these the supposed 
"VTAM jargon"?


I even went to the Google archive to check since it appeared I must have 
missed a post.


As others indicate below - but without highlighting the actionable and 
completely unfounded slur on VTAM - whatever the perceived problem here is, 
VTAM is as innocent as a new-born babe. VTAM has no interest whatsoever in 
userids and DD-names or whatever is standing in the way of the subject under 
discussion. Thus "getting rid of VTAM" is utterly irrelevant.


"Feelings" and "suspicions" are bad mentors when tying to steer technical 
discussions.


Chris Mason

[1] Since religion has been introduced, the word "bigotry" also comes to 
mind. But there's always hope, look at Ulster - or - as some say - "the six 
counties".


- Original Message - 
From: "Paul Gilmartin" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, June 13, 2007 9:03 PM
Subject: Re: Multiple TSO logons (was: Patents, ...)



On Wed, 13 Jun 2007 13:48:19 -0400, Kirk Talman wrote:


More accurately, single ID, single LPAR, single application, multiple
session facility.


I stand corrected.  Thanks.


That is an application issue.  E.g., we have two TORs using a single
AOR/FOR pair.  For some transactions we disallowed using both AORs at the
same time in the transaction's security signon part because the
transaction was not sophisticated enough to build temp storage queue names
to distinguish simultaneous signins (and related issues).  And it was
deemed not worth the effort to correct that.


Theology.  Dogma.  Simply to start doing it right, you must
stop doing it wrong.  Somehow I feel a major culprit is VTAM
because whenever this issue arises an expert starts spouting
VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
the TMP input/output data streams.


For TSO and whatever TCAS is called now, the issue becomes having the
address space name created be different from the userid.  What would that
break?

To have the session manager handle that wrinkle using e.g. morphing the
userid used at signon and then having the security system or application
handle the authorization via unmorphing the userid is messy. btdtgt-scars.


Somehow this all works for batch EXEC PGM=IKJEFT01, which I am told
is the same TMP.  Seems like a solved problem.  I suspect it only
works because there's no VTAM in the way.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Ted MacNEIL]

>Didn't JES2 enforce unique TSU job ids in a MAS?  Was this ever changed?

This was changed around OS/390 2.7.
And, I have exploited it on a z/OS 1.4 & 1.7 system.

I wrote an article that has a sample EXEC to allow you to invoke multiple 
sign-ons, but there is one point that is incorrect (you can only sign on once 
per image).

10) November 2006: "Digging Into the Bag of ISPF Tricks"
http://tinyurl.com/yyghzr

The execs mentioned in the article are also on the CBT Tape.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Greg Price]

Paul Gilmartin wrote:
> On Thu, 14 Jun 2007 20:30:43 -0500, Tony Harminc wrote:
>> I've looked at this, and "it isn't pretty" doesn't even begin to describe
>> it. Unless IBM has severely modularized things since the last non-OCO
>> version of this stuff, it is full of hardcoded knowledge of not only VTAM
>> (and TCAM!) module names, but of their various quirky behaviours.
>>
> So how does IKJEFT01 in batch bypass all that stuff?  How does it bridge
> the userid==address space name pitfall?
> 
> -- gil


Some of the things that rely on userid=jobname probably include
inter-ASID TPUT (incl. OS SEND command) and LOGON RECONNECT.

If you are not fussed about those two things (and anything else that
I should have listed) then it is "easy" to allow a single TSO-authorised
userid to logon to TSO multiple times concurrently on a single "MVS"
image.

(Stroking chin for flashback sequence...) It all began because for years
I wanted the RACF user name (of up to 20 characters) to be placed into
the programmer name field of the JOB card of the TSO session's JCL.

I complained about this somewhere - maybe even here - and whined about
a RACF deficiency when compared to ACF2 which does do this.  Walt the
RACF wizard kindly pointed out that this is not up to RACF to do but TSO.

So, whipping up a TSO Logon Post-Prompt Exit (IKJEFLD3) from the
sample, the RACF user name went into the JOB card.  Nice.

Now, for my next trick, I change IKJEFLD3 to fiddle the job name by adding
a character after the TSO userid (which has a max length of 7 chars)
to form the new job name.  This allows up to 40 TSO user address spaces
from the one id (blank or "TSO classic", 26 alphabetic, 10 numeric, and
3 national).

Oh, and of course the other thing to handle is the SYSIKJUA ENQ on
the userid.  This is deftly dealt with by cunningly converting these ENQs
to shared (instead of exclusive) - achieved by a simple front-end to SVC 56.

Warning: the way I did it makes no allowance for SYSPLEX or shared SPOOL
(Didn't JES2 enforce unique TSU job ids in a MAS?  Was this ever changed?)
because the decision of which suffix character to use for the job name is
made by scanning the address space names in the virtual storage of *this*
system only.

It all seemed to work okay but it was OS/390 and not the most heavily-loaded
system in the world (although I still think it would work on z/OS and I don't
think system load affects it's viability).  And as I say, the ability to LOGON
RECONNECT goes out the window, which may not be an issue if you use
session manager software or have a reliable network.

And as far the ISPF profile data set, we settled on a scheme where the
session's profile data set (perhaps userid.jobname.ISPPROF) was cloned
from the user's original or base profile data set by the logon CLIST.  It may
have even been deleted and cloned anew each time so that updates to
the base profile got promulgated.  And I may have even written a function
which returned the current job name into a CLIST variable.

The method is described in member MULTITSO of CBT file 134.  The JCL and
source code for the TSO exit and the SVC 56 front-end and its loader are
also present in other members of that file.

And that was about six and a half years ago... (stops stroking chin).

Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Fri, 15 Jun 2007 08:39:30 -0500, Mark Zelden wrote:
>>>
>>So how does IKJEFT01 in batch bypass all that stuff?  How does it bridge
>>the userid==address space name pitfall?
>
>SMOP of course.
>Oh... you want details?
>
No, "SMOP" is quite the answer I wanted.  And it appears that
some of the Programming, such as decoupling the userid from the
address space has already been done.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Mark Zelden]

On Thu, 14 Jun 2007 21:00:27 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
>>
>So how does IKJEFT01 in batch bypass all that stuff?  How does it bridge
>the userid==address space name pitfall?
>

SMOP of course.  

Oh... you want details?

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Thu, 14 Jun 2007 20:30:43 -0500, Tony Harminc wrote:
>
>I've looked at this, and "it isn't pretty" doesn't even begin to describe
>it. Unless IBM has severely modularized things since the last non-OCO
>version of this stuff, it is full of hardcoded knowledge of not only VTAM
>(and TCAM!) module names, but of their various quirky behaviours.
>
So how does IKJEFT01 in batch bypass all that stuff?  How does it bridge
the userid==address space name pitfall?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Tony Harminc]

On Wed, 13 Jun 2007 14:03:15 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>Theology.  Dogma.  Simply to start doing it right, you must
>stop doing it wrong.  Somehow I feel a major culprit is VTAM
>because whenever this issue arises an expert starts spouting
>VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
>the TMP input/output data streams.

I've looked at this, and "it isn't pretty" doesn't even begin to describe
it. Unless IBM has severely modularized things since the last non-OCO
version of this stuff, it is full of hardcoded knowledge of not only VTAM
(and TCAM!) module names, but of their various quirky behaviours.

This is one of those situations where everyone agrees that it would be a
Good Thing to replace some part of the legacy stuff, but everyone disagrees
on just which parts are legacy junk, and which are the very core of the
architecture.

When I worked for Amdahl/Antares on Huron, we had complete control over the
applications that drove 3270 screens, and once all the real green-screens
had gone away, it began to make sense to consider designing our own new 3270
protocol along with an emulator that would exploit it. But it never
happened, because there were just too many layers (CICS, VTAM, TSO, ...)
that all had to be fixed at exactly the same time.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[John S. Giltner, Jr.]

Paul Gilmartin wrote:

On Wed, 13 Jun 2007 13:48:19 -0400, Kirk Talman wrote:



More accurately, single ID, single LPAR, single application, multiple
session facility.



I stand corrected.  Thanks.



That is an application issue.  E.g., we have two TORs using a single
AOR/FOR pair.  For some transactions we disallowed using both AORs at the
same time in the transaction's security signon part because the
transaction was not sophisticated enough to build temp storage queue names
to distinguish simultaneous signins (and related issues).  And it was
deemed not worth the effort to correct that.



Theology.  Dogma.  Simply to start doing it right, you must
stop doing it wrong.  Somehow I feel a major culprit is VTAM
because whenever this issue arises an expert starts spouting
VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
the TMP input/output data streams.



Has nothing to do with VTAM.  We allow users to logon as many times as 
they want to our TOR and execute the same transactions no matter what. 
There is nothing in VTAM that prevents this.


IIRC even using TCP/IP CICS builds a LU name under the covers. The LU 
name happens to be the hex value of the IP address.  So if your IP 
address is 10.10.10.10, your LU name is 0A0A0A0A.


My guess is that the program was building TS queues based on the full, 
or part of the userid.   One userid, one TS queue.


Whereas our programs build TS queue names based on the TERMID (the 4 
character CICS TERMID).  The same user logging on from 4 different 
terminals can easily have 4 TS queues.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Craddock, Chris
> > 
> 
> > 
> > To address the "who would pay for it?" question; the original
business 
> > plan called for a per-seat license of a couple of hundred bucks per 
> > seat, which would be somewhat like an MS Office price. We got
positive 
> > feedback from a bunch of customers for that price point.
Unfortunately 
> > when the product was done, the pricing geniuses couldn't figure out 
> > how to do a per-seat deal and turned it into a tiered price monster 
> > starting at something like $25K for the bottom tier. It's no wonder 
> > nobody bought it at that sort of price.
> 
> Sounds like a lot of "marketting" that I've heard of. And it 
> seems that management of a company would rather throw the 
> entire product into the dumpster rather than decide to 
> release the source to the community with a disclaimer along 
> the lines of "take this and do what you want. We can't sell 
> it, but we've already spent the money to develop it. Don't 
> expect any support from us, but think of us kindly if you use 
> it and find it helpful to you." There may be some legal 
> reason to do this. But such a system, perhaps released under 
> the GPL (I like the GPL,
> generally) would likely generate some "good will" towards the company.
> Being a techie-type idiot, I just don't see why "giving it 
> away for free" is somehow worse than just trashing it. Either 
> way, the money is spent and none is coming in.

You're thinking logically again...  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris
> Sent: Wednesday, June 13, 2007 3:51 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple TSO logons (was: Patents, ...)
> 

> 
> To address the "who would pay for it?" question; the original business
> plan called for a per-seat license of a couple of hundred bucks per
> seat, which would be somewhat like an MS Office price. We got positive
> feedback from a bunch of customers for that price point. Unfortunately
> when the product was done, the pricing geniuses couldn't 
> figure out how
> to do a per-seat deal and turned it into a tiered price 
> monster starting
> at something like $25K for the bottom tier. It's no wonder 
> nobody bought
> it at that sort of price.
> 
> CC

Sounds like a lot of "marketting" that I've heard of. And it seems that
management of a company would rather throw the entire product into the
dumpster rather than decide to release the source to the community with
a disclaimer along the lines of "take this and do what you want. We
can't sell it, but we've already spent the money to develop it. Don't
expect any support from us, but think of us kindly if you use it and
find it helpful to you." There may be some legal reason to do this. But
such a system, perhaps released under the GPL (I like the GPL,
generally) would likely generate some "good will" towards the company.
Being a techie-type idiot, I just don't see why "giving it away for
free" is somehow worse than just trashing it. Either way, the money is
spent and none is coming in.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Craddock, Chris]

> >I know BMC did something like this with z/OS Explorer, but who would
pay
> >for it?  No one I could find.
> >
> Is HOD anything of the sort?

Nope. Completely different. The z/OS System Explorer was/is a single
address space server that provided a (Java) GUI interface for most of
the things you would typically do under ISPF and SDSF. File browse/edit
(using your own choice of editor), search/compare, dataset manipulation,
job submission, job output management yada yada yada. And there were
plans for a set of product functions that would plug into the same
infrastructure and UI. 

It was a lot more efficient and easier to use for a lot of the most
common things people do, but you couldn't really call it a replacement
for TSO because among other things, it didn't do native TSO things like
CLISTs etc.

There were many differences from TSO, starting with the fact that it had
nothing at all to do with TSO. The TMP was not used, even under the
covers. There wasn't any screen scraping or terminal emulation. It was a
real native multi-user GUI application that followed the MVS rules. 

To address the "who would pay for it?" question; the original business
plan called for a per-seat license of a couple of hundred bucks per
seat, which would be somewhat like an MS Office price. We got positive
feedback from a bunch of customers for that price point. Unfortunately
when the product was done, the pricing geniuses couldn't figure out how
to do a per-seat deal and turned it into a tiered price monster starting
at something like $25K for the bottom tier. It's no wonder nobody bought
it at that sort of price.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Howard Brazee]

On 13 Jun 2007 13:21:46 -0700, in bit.listserv.ibm-main you wrote:

>>Easy to say get rid of VTAM, but much harder to do.  Would you just
>>trade your 3270 emulator for a web page interface?  Then it might be
>>something you could do.
>>
>???
>
>My terminal emulators (I use a couple) already speak TCP/IP (TN3270 
>to be precise).  Why would a web page interface be necessary, or
>even helpful?

Work from your iPhone?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Wed, 13 Jun 2007 14:26:39 -0500, McKown, John wrote:
>
>/* REXX */
>parse arg incmd
>address tso incmd
>
>Anything you can do in "batch TSO" can be run this way. But you need to
>watch out that the UNIX shell doesn't do anything funny with your
>command. You can usually avoid this by enclose the command in "double
>ticks"
>
I have something similar.  It uses "parse pull" in a loop, which
avoids the shell lexical transformations.  And since the TSO
address space continues running in background, I can issue
sequences of commands, such as several ALLOCATEs and a CALL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Wed, 13 Jun 2007 14:09:54 -0500, Tom Moulder wrote:
>>>
>> stop doing it wrong.  Somehow I feel a major culprit is VTAM
>> because whenever this issue arises an expert starts spouting
>> VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
>> the TMP input/output data streams.
>>
>Easy to say get rid of VTAM, but much harder to do.  Would you just
>trade your 3270 emulator for a web page interface?  Then it might be
>something you could do.
>
???

My terminal emulators (I use a couple) already speak TCP/IP (TN3270 
to be precise).  Why would a web page interface be necessary, or
even helpful?

>I know BMC did something like this with z/OS Explorer, but who would pay
>for it?  No one I could find.
>
Is HOD anything of the sort?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Bruce Black]

but
  

> every developer had multiple TSO ID's that were almost all logged on


all
  

> the time since this was before session managers.



Ah the good old days! Oddly enough even with session managers, this is
still the way most people work. Only today the number of sessions per
user is probably up to 4 or more.
Personally I normally run two TSO IDs, one in 80-column mode, one in 
132-column mode for viewing listings.


Plus we have multiple LPARs without shared spool (independent spool) so 
I have a couple of IDs in reserve for when I need to signon to another LPAR.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Wednesday, June 13, 2007 2:03 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple TSO logons (was: Patents, ...)
> 



> Somehow this all works for batch EXEC PGM=IKJEFT01, which I am told
> is the same TMP.  Seems like a solved problem.  I suspect it only
> works because there's no VTAM in the way.
> 
> -- gil

You can execute "line mode" TSO commands from a UNIX shell using a very
simple REXX program, which I call "tso_cmd":

/* REXX */
parse arg incmd
address tso incmd


Anything you can do in "batch TSO" can be run this way. But you need to
watch out that the UNIX shell doesn't do anything funny with your
command. You can usually avoid this by enclose the command in "double
ticks"

tso_cmd "listc lvl('sys1')"

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Tom Moulder]

<< snip >>




Theology.  Dogma.  Simply to start doing it right, you must
stop doing it wrong.  Somehow I feel a major culprit is VTAM
because whenever this issue arises an expert starts spouting
VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
the TMP input/output data streams.

  

<< snip >>



Somehow this all works for batch EXEC PGM=IKJEFT01, which I am told
is the same TMP.  Seems like a solved problem.  I suspect it only
works because there's no VTAM in the way.

-- gil

  
Easy to say get rid of VTAM, but much harder to do.  Would you just 
trade your 3270 emulator for a web page interface?  Then it might be 
something you could do.


I know BMC did something like this with z/OS Explorer, but who would pay 
for it?  No one I could find.


Tom Moulder

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Wed, 13 Jun 2007 13:48:19 -0400, Kirk Talman wrote:

>More accurately, single ID, single LPAR, single application, multiple
>session facility.
>
I stand corrected.  Thanks.

>That is an application issue.  E.g., we have two TORs using a single
>AOR/FOR pair.  For some transactions we disallowed using both AORs at the
>same time in the transaction's security signon part because the
>transaction was not sophisticated enough to build temp storage queue names
>to distinguish simultaneous signins (and related issues).  And it was
>deemed not worth the effort to correct that.
>
Theology.  Dogma.  Simply to start doing it right, you must
stop doing it wrong.  Somehow I feel a major culprit is VTAM
because whenever this issue arises an expert starts spouting
VTAM jargon.  Get rid of VTAM; let TCP/IP connect directly to
the TMP input/output data streams.

>For TSO and whatever TCAS is called now, the issue becomes having the
>address space name created be different from the userid.  What would that
>break?
>
>To have the session manager handle that wrinkle using e.g. morphing the
>userid used at signon and then having the security system or application
>handle the authorization via unmorphing the userid is messy. btdtgt-scars.
>
Somehow this all works for batch EXEC PGM=IKJEFT01, which I am told
is the same TMP.  Seems like a solved problem.  I suspect it only
works because there's no VTAM in the way.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple TSO logons (was: Patents, ...)

[Kirk Talman]

More accurately, single ID, single LPAR, single application, multiple 
session facility.

That is an application issue.  E.g., we have two TORs using a single 
AOR/FOR pair.  For some transactions we disallowed using both AORs at the 
same time in the transaction's security signon part because the 
transaction was not sophisticated enough to build temp storage queue names 
to distinguish simultaneous signins (and related issues).  And it was 
deemed not worth the effort to correct that.

For TSO and whatever TCAS is called now, the issue becomes having the 
address space name created be different from the userid.  What would that 
break?

To have the session manager handle that wrinkle using e.g. morphing the 
userid used at signon and then having the security system or application 
handle the authorization via unmorphing the userid is messy. btdtgt-scars.

I am reminded of the old commercial with the tag line "It's not nice to 
fool mother nature."

IBM Mainframe Discussion List  wrote on 06/13/2007 
12:45:27 PM:

> Do session managers in any way alleviate the problem of DDNAME
> collisions?  Do multiple IDs cause concern to security auditors?
> I still wish for the advent of the single ID single LPAR multiple
> session facility.

> -- gil


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. The information may also constitute a legally
privileged confidential communication. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message. Thank you

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Multiple TSO logons (was: Patents, ...)

[Paul Gilmartin]

On Wed, 13 Jun 2007 10:16:13 -0500, Tom Moulder wrote:
>
>By the way, there were not 75 developers at BMC in this time frame, but
>every developer had multiple TSO ID's that were almost all logged on all
>the time since this was before session managers.
>
Do session managers in any way alleviate the problem of DDNAME
collisions?  Do multiple IDs cause concern to security auditors?
I still wish for the advent of the single ID single LPAR multiple
session facility.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html