All the gory details and caveats are discussed here on my web
site and CBT file 434 (I just updated information and caveats
related to sharing the same profile data set on multiple
systems):
http://home.flash.net/~mzelden/mvsfiles/$sngltso.txt
Regards,
Mark
--
Mark Zelden
Sr. Software and System
In <[EMAIL PROTECTED]>, on 08/29/2005
at 12:09 PM, Bill Fairchild <[EMAIL PROTECTED]> said:
>Being a HASP/JES2 bigot for 10 years a long time ago, my favorite
>SHARE button said "JES2 may be Mickey Mouse, but JES3 is Goofy."
"JES2 is half-ASP."
Then there was the snail on top of the turtle
In
<[EMAIL PROTECTED]>,
on 08/29/2005
at 11:30 AM, "Craddock, Chris" <[EMAIL PROTECTED]> said:
>The JES projects at share definitely "get along".
And have for decades. That comes in handy when IBM plays pass the buck
("That's not a TSO problem, it's a JES problem. That's not a JES
problem, it'
In <[EMAIL PROTECTED]>, on 08/29/2005
at 04:00 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Most of these, according to DDLIST:
Those are temporary data sets, which don't need special handling for
duplicate job names. However, both TSO and ISPF generate permanent
data sets as well, which do h
Bill Fairchild wrote:
In a message dated 8/29/2005 11:03:19 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
One of my favorite SHARE buttons, maybe a Howard Dean special
was the summa cum JES. 'Get it up once, keep it up forever'.
Is there a JES unification project left?
In a recent note unmask]> said:
> Date: Mon, 29 Aug 2005 17:52:03 -0500
>
> Shutting off propagation of the Enqueue for PROFILE would only
> apply to logging on to multiple systems in the sysplex. It would
> not help if you wanted to log on the same image agani. The ISPF
> LOG might be a
In a recent note unmask]> said:
> Date: Mon, 29 Aug 2005 18:05:42 -0500
>
> All such schemes tend to run aground on the problem that the reason the
> ENQ was there in the first place was to avoid corrupting the dataset(s)
> in question. If there was no need for such serialization the ENQ
>
> Shutting off propagation of the Enqueue for PROFILE would only
> apply to logging on to multiple systems in the sysplex. It would
> not help if you wanted to log on the same image agani. The ISPF
> LOG might be a bigger issue if you wanted multiple concurrent
> logons to the same system.
All s
Shutting off propagation of the Enqueue for PROFILE would only
apply to logging on to multiple systems in the sysplex. It would
not help if you wanted to log on the same image agani. The ISPF
LOG might be a bigger issue if you wanted multiple concurrent
logons to the same system.
Tom Marchant
O
In a recent note, Tom Marchant said:
> Date: Mon, 29 Aug 2005 15:41:05 -0500
>
> It allows multiple started tasks with the same name. As others
> have mentioned, there would need to be a way to handle numerous
> data sets, including ISPF profile, log and list.
>
Most of these, according
It allows multiple started tasks with the same name. As others
have mentioned, there would need to be a way to handle numerous
data sets, including ISPF profile, log and list.
Tom Marchant
On Mon, 29 Aug 2005 14:21:04 -0600, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
>Does this mean, IOW, that an
>Does this mean, IOW, that an installation can preserve
uniqueness for Batch jobs, but allow concurrency for
TSO jobs?
...
Yes.
Because people wanted to 'preserve' the sybchronisation for Batch and sign-on
multiple times to TSO.
-teD
In God we Trust!
All others bring data!
-- W. Edwards Demin
gt; Subject: Re: Future ISPF directions (was: Re: How Was Share?)
> Content-type: text/plain
>
> >I suspect the same JES2 user resistance is still there.
> ...
>
> If you're resistant, don't turn on the option.
>
Such options should, by good design, be availa
In a message dated 8/29/2005 3:07:38 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>If you're resistant, don't turn on the option.
>You can do it for TSO and Batch separately.
It appears that my ancient knowledge of JES2 features is down-level.
Bill Fairchild
-
>I suspect the same JES2 user resistance is still there.
...
If you're resistant, don't turn on the option.
You can do it for TSO and Batch separately.
-teD
In God we Trust!
All others bring data!
-- W. Edwards Deming
--
For
> There is no JES unification project at SHARE. IBM has given up on
> unifying JES. From the SHARE perspective it would appear to make sense
> to combine the JES2 and JES3 Projects, but one would wind up with a
> nominal JES Project Manager and two committees, one for JES2 and one
for
> JES3. Since
There is no JES unification project at SHARE. IBM has given up on
unifying JES. From the SHARE perspective it would appear to make sense
to combine the JES2 and JES3 Projects, but one would wind up with a
nominal JES Project Manager and two committees, one for JES2 and one for
JES3. Since the JES3
Well you know what they say "JES2 is only half ASP".
>>> [EMAIL PROTECTED] 8/29/2005 12:09:00 PM >>>
In a message dated 8/29/2005 11:03:19 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>One of my favorite SHARE buttons, maybe a Howard Dean special
>was the summa cum JES. 'Get it up
In a message dated 8/29/2005 11:03:19 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>One of my favorite SHARE buttons, maybe a Howard Dean special
>was the summa cum JES. 'Get it up once, keep it up forever'.
>Is there a JES unification project left?
Being a HASP/JES2 bigot for 1
In a message dated 8/29/2005 10:58:39 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
acknowledgment of "old school" shops that actually depend on duplicate
job name queuing as a primitive form of serialization. We run multiple
jobs with the same name all the time!
>>
One of my f
Bill Fairchild wrote:
A long time ago IBM wanted to do this, took a user survey, and found that a
large number of JES2 shops were relying on JES2's "feature" (really a
restriction since day one of HASP) of not letting more than one job with the same
jobname start executing. Users were usin
In a message dated 8/29/2005 10:35:21 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>IBM could easily support multiple
>sessions with the same name and allow ASID on the CANCEL command
A long time ago IBM wanted to do this, took a user survey, and found that a
large number of JE
In <[EMAIL PROTECTED]>, on 08/27/2005
at 11:21 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>I did. Thanks. It discusses logons on different LPARs. This is
>underreaching. Why not multiple logons on a single LPAR? The
>integrity and serialization issues ought to be the same; the sole
>obvi
In <[EMAIL PROTECTED]>, on 08/27/2005
at 09:33 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>As you can guess, or already know, I'm an eager partisan for Multiple
>Logon. We've achieved it at our site for multiple systems (but not
>on any single system) simply by blocking MIM's propagation of
In a recent note, Thomas Conley said:
> Date: Sat, 27 Aug 2005 12:10:04 -0400
>
> Multiple logon is here now, with caveats. We're trying to resolve the
> issues we know about. Check out
> http://www.naspa.com/PDF/2004/0504/T0405002.pdf to get started. Also check
>
I did. Thanks. It d
Gil,
My comments below.
Tom
- Original Message -
From: "Paul Gilmartin" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Saturday, August 27, 2005 11:33 AM
Subject: Future ISPF directions (was: Re: How Was Share?)
In a recent note, Thomas Con
In a recent note, Thomas Conley said:
> Date: Sat, 27 Aug 2005 00:29:31 -0400
>
> laughed at my jokes, and I began my next SHARE-based crusade (out with
> Dynamic ISPF, in with multiple logon). I had a fantastic time at this
>
Had to look up Dynamic ISPF at:
http://www.frontiernet.
27 matches
Mail list logo
