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 conne
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
lt;>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
ce 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
>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
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 on
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 Pro
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
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
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
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 tr
> -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 calle
> -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 addres
> >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
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
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
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
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
> -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
<< 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.
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
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
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 th
23 matches
Mail list logo
