Re: TSO "concern" - sysplex multisystem logon.

[Shmuel Metz (Seymour J.)]

In <0486882064432540.wa.paulgboulderaim@bama.ua.edu>, on
12/21/2011
   at 12:02 PM, Paul Gilmartin  said:

>Hmmm...  IIRC, there are certain authorized utilities that will run
>only in a single-step job.  They check.

No. The check is before the ATTACH of the started program. I believe
that the test is in STC.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Shmuel Metz (Seymour J.)]

In
,
on 12/21/2011
   at 05:39 PM, "Vernooij, CP - SPLXM"  said:

>Yes, there is a light at the horizon: you cannot FREE a dataset
>allocated in JCL.

Wherever did you get that idea? Not only can you, but lots of
installations have logon clists that do just that.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Chris Mason]

Paul

> ... IIRC ...

I'm a touch surprised you are not confidently familiar with this topic! Unless 
it is I who am not quite as familiar as I might be, the point being that, when 
"multi-step" is tried with a TSO user procedure, the reaction is *not* the more 
familiar one, namely message "IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED" - 
more later.

> ... there are certain authorized utilities that will run only in a 
> single-step job. They check.

The usual cause of the "single step" limitation is the specification of SYST in 
the IEFSDPPT CSECT in module IEFSD060. The affected programs can be found in 
Table 23, "IBM-supplied Program Properties Table (PPT) Values" in section 
"Program properties table (PPT)" of the "z/OS MVS Initialization and Tuning 
Reference" manual.
 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2c0/76.7

Check the "ST" column.

The significance is explained in the description of the SYST attribute in 
adjacent section "Statements/parameters for SCHEDxx" in the manual.

I guess I should add that similar considerations apply to attribute "NODSI" - 
now that I check my sources!

-

When I first lit upon this thread stream - in reverse - I notices that a - I 
imagined initially *the* - "single step" limitation was what was causing the 
problem. Then I found John's post where he tried a two step TSO logon procedure 
and was hit by message "IKJ56457I LOGON FAILED MULTIPLE STEPS SPECIFIED IN 
LOGON PROCEDURE," for his pains, not the expected IEF188I.

Finally, I failed to find IKJEFT01 in Table 23[1] and so, whatever checking is 
going on in the case of program IKJEFT01 it is *not* under the auspices of 
whatever programming is directed by the "Program Properties Table".

All this brought me round to the idea that these "utilities" to which you refer 
may also not be dependent on the "Program Properties Table".

Possibly the only point in bringing this up is to be sure that any relatively 
novice system programmers reading this are aware that not all "single step" 
limitations can be attributed to "NODSI" and "SYST".

-

> I don't know why it matters.

Incidentally, many years ago now whenever, with the aid of a SCHEDxx member PPT 
statement, I have "removed" the SYST attribute for various "networking" 
programs found in the famous Table 23 and set up multi-step procedures for 
"started tasks", for example, VTAM, nothing untoward occurred. As far as the 
"SYST" attribute is concerned, I think it must be a fossil of something that 
mattered once - very many years ago - but whatever it was has long since 
disappeared but no developer has ever felt bold enough to throw it away!

-

[1] I bet Johgn checked this too before he tried his TSO logon procedure with 
two steps.

-

Chris Mason

On Wed, 21 Dec 2011 12:02:12 -0600, Paul Gilmartin  wrote:

>On Wed, 21 Dec 2011 11:56:26 -0600, McKown, John wrote:
>>
>>Gee, I never saw a TSO logon proc with more than one step. Never would have 
>>occurred to me.
>>
>Hmmm...  IIRC, there are certain authorized utilities that will
>run only in a single-step job.  They check.  I don't know why
>it matters.  I don't know where TSO plays in this game.
>
>-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Andrews
> Sent: Wednesday, December 21, 2011 10:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO "concern" - sysplex multisystem logon.
> 
> On Wed, 2011-12-21 at 11:06 -0500, McKown, John wrote:
> > allow certain people the ability to logon to TSO on all systems
> > concurrently. It appears this is possible, for all users, simply by
> > not propagating the SYSIKJUA enqueue via the GRSRNL.
> 
> The SYSIKJUA RNAME appears to be the TSO userid:
> 
>   11.24.59   d grs,res=(sysikjua,*)   
>
>   11.24.59   ISG343I 11.24.59 GRS STATUS 499  
>
>   S=SYSTEM  SYSIKJUA DBA  
>
>   SYSNAMEJOBNAME ASID TCBADDR   
> EXC/SHRSTATUS
>   PROD 0038   008FFB00 
> EXCLUSIVEOWN  
> 
> So could you specify your own (and other privileged ones) RNAME as an
> RNL exclude?
> 
> -- 
> David Andrews

I don't know why that didn't occur to me. I'm not too good with multisystem 
stuff. Little experience in a truly large shop. Any reason why the following 
wouldn't work? I can't test anymore until we go live:

RNLDEF RNL(INCL) TYPE(GENERIC)  QNAME(SYSIKJUA)
RNLDEF RNL(EXCL) TYPE(PATTERN)  QNAME(SYSIKJUA)  RNAME(ABC*)
RNLDEF RNL(EXCL) TYPE(PATTERN)  QNAME(SYSIKJUA)  RNAME(DEF*)


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Binyamin Dissen
> Sent: Wednesday, December 21, 2011 11:59 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO "concern" - sysplex multisystem logon.
> 
> On Wed, 21 Dec 2011 11:41:08 -0600 "McKown, John"
>  wrote:
> 
> :>> Curious as to why you wish to prevent it. If they can 
> :>> arbitrarily choose to
> :>> logon to any system, why prevent concurrent logons?
> 
> :>Because my boss said so. He didn't say why. I don't argue 
> any more. We are "CPU poor" and our programmer's generally 
> are "gluttons". They use FileAid in TSO to edit and change 
> __HUGE__ datasets, rather than write an ICETOOL batch job. 
> They do it over, and over, and over. 
> 
> I see. No (or inadequate) chargeback.
> 
> --
> Binyamin Dissen 

No chargeback at all. Not even any reports for management. IT is "pure 
overhead". So our budget is very difficult to justify. We are eliminating 
software and hardware as much as possible to reduce "our" budget. But the users 
still demand service. And don't care about cost, because they are not charged. 
Not good, but nothing that I can do anything about. I'm just a "grunt" who's on 
the front line getting shot at. Not an "bean counter" in the Congress who looks 
only at the cost (not the value). Our users are like city citizens: They want 
good schools, police and fire protection. But scream about paying taxes. 
TANSTAAFL.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Frank Swarbrick]

Argh.

Why *wouldn't* you want to edit a file using FileAid in TSO.  That's what it's 
for!  If it can't handle doing what it is built to do then perhaps there is 
something wrong with the tool.


How does disallowing concurrent logons force one to not do this?  Or is it just 
punishment?  "If you promise not to do that any more I'll allow you to access 
more than one system concurrently."

If it's (the FileAid issue) really an issue shouldn't management deal with the 
actual issue directly, rather than do some weird, seemingly unrelated technical 
workaround?

If someone tried to restrict me from accessing production and development 
systems concurrently I'd throw a fit.


Honestly, your job sounds like a nightmare!


Signed, 

A Programmer




>
> From: "McKown, John" 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Wednesday, December 21, 2011 10:41 AM
>Subject: Re: TSO "concern" - sysplex multisystem logon.
> 
>
>> 
>> Curious as to why you wish to prevent it. If they can 
>> arbitrarily choose to
>> logon to any system, why prevent concurrent logons?
>> 
>> --
>> Binyamin Dissen 
>> http://www.dissensoftware.com
>> 
>> Director, Dissen Software, Bar & Grill - Israel
>
>Because my boss said so. He didn't say why. I don't argue any more. We are 
>"CPU poor" and our programmer's generally are "gluttons". They use FileAid in 
>TSO to edit and change __HUGE__ datasets, rather than write an ICETOOL batch 
>job. They do it over, and over, and over. 
>
>--
>John McKown 
>Systems Engineer IV
>IT
>
>Administrative Services Group
>
>HealthMarkets(r)
>
>9151 Boulevard 26 * N. Richland Hills * TX 76010
>(817) 255-3225 phone * 
>john.mck...@healthmarkets.com * www.HealthMarkets.com
>
>Confidentiality Notice: This e-mail message may contain confidential or 
>proprietary information. If you are not the intended recipient, please contact 
>the sender by reply e-mail and destroy all copies of the original message. 
>HealthMarkets(r) is the brand name for products underwritten and issued by the 
>insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
>Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
>MEGA Life and Health Insurance Company.SM
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Paul Gilmartin]

On Wed, 21 Dec 2011 11:56:26 -0600, McKown, John wrote:
>
>Gee, I never saw a TSO logon proc with more than one step. Never would have 
>occurred to me.
> 
Hmmm...  IIRC, there are certain authorized utilities that will
run only in a single-step job.  They check.  I don't know why
it matters.  I don't know where TSO plays in this game.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Vernooij, CP - SPLXM]

"Paul Gilmartin"  wrote in message
news:<8844286434605726.wa.paulgboulderaim@bama.ua.edu>...
> On Wed, 21 Dec 2011 19:22:31 +0200, Binyamin Dissen wrote:
> 
> >On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM" wrote:
> >
> >:>Yes, there is a light at the horizon: you cannot FREE a dataset
> >:>allocated in JCL. So this trick might well be the solution.
> >
> >You certainly can.
> > 
> What if he were to add a subsequent IEFBR14,COND=(0,LE) step
> allocating the same DSN?
> 
> 

Good point. 
Benjamin sounds quite certain, and I judge his opinion high and don't
wanna doubt it without proof, but the subsequent step must be the killer
solution.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Binyamin Dissen]

On Wed, 21 Dec 2011 11:41:08 -0600 "McKown, John"
 wrote:

:>> Curious as to why you wish to prevent it. If they can 
:>> arbitrarily choose to
:>> logon to any system, why prevent concurrent logons?

:>Because my boss said so. He didn't say why. I don't argue any more. We are 
"CPU poor" and our programmer's generally are "gluttons". They use FileAid in 
TSO to edit and change __HUGE__ datasets, rather than write an ICETOOL batch 
job. They do it over, and over, and over. 

I see. No (or inadequate) chargeback.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Vernooij, CP - SPLXM]

"McKown, John"  wrote in message
news:.
..
> 
> > 
> > Curious as to why you wish to prevent it. If they can 
> > arbitrarily choose to
> > logon to any system, why prevent concurrent logons?
> > 
> > --
> > Binyamin Dissen 
> > http://www.dissensoftware.com
> > 
> > Director, Dissen Software, Bar & Grill - Israel
> 
> Because my boss said so. 

Dzjee, in what country are you? I heard this before and I cannot imagine
the (at this level of detail) happening here. But I must admit, Barbara
also complained about it, so maybe I am just lucky that my boss accepts
that I can be trusted on the technical issues. I trust him to deal well
with the organizational issues.

Kees.



He didn't say why. I don't argue any more. We are "CPU poor" and our
programmer's generally are "gluttons". They use FileAid in TSO to edit
and change __HUGE__ datasets, rather than write an ICETOOL batch job.
They do it over, and over, and over. 
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * 
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential
or proprietary information. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message. HealthMarkets(r) is the brand name for products
underwritten and issued by the insurance subsidiaries of HealthMarkets,
Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life
Insurance Company of TennesseeSM and The MEGA Life and Health Insurance
Company.SM
> 
>  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Binyamin Dissen]

On Wed, 21 Dec 2011 11:42:15 -0600 Paul Gilmartin 
wrote:

:>On Wed, 21 Dec 2011 19:22:31 +0200, Binyamin Dissen wrote:
:>>On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM" wrote:

:>>:>Yes, there is a light at the horizon: you cannot FREE a dataset
:>>:>allocated in JCL. So this trick might well be the solution.

:>>You certainly can.
> 
:>What if he were to add a subsequent IEFBR14,COND=(0,LE) step
:>allocating the same DSN?

IIRC, TSO must be a single step.

:>On Wed, 21 Dec 2011 19:23:47 +0200, Binyamin Dissen wrote:

:>>Curious as to why you wish to prevent it. If they can arbitrarily choose to
:>>logon to any system, why prevent concurrent logons?
 
:>Think, "managers."  (Actually, I think his concern was synchronizing
:>profile updates.)

With a good chargeback method, the end-users manager would handle it.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[McKown, John]

Ah. no wonder I've never seen a multistep TSO logon proc. I just tried:

IKJ56455I TSH009 LOGON IN PROGRESS AT 12:00:55 ON DECEMBER 21, 2011,
IKJ56457I LOGON FAILED MULTIPLE STEPS SPECIFIED IN LOGON PROCEDURE,
IKJ56470I TSH009 LOGGED OFF TSO AT 12:00:55 ON DECEMBER 21, 2011,
IKJ56400A ENTER LOGON OR LOGOFF-,

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John
> Sent: Wednesday, December 21, 2011 11:56 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO "concern" - sysplex multisystem logon.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> > Sent: Wednesday, December 21, 2011 11:42 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: TSO "concern" - sysplex multisystem logon.
> > 
> > On Wed, 21 Dec 2011 19:22:31 +0200, Binyamin Dissen wrote:
> > 
> > >On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM" wrote:
> > >
> > >:>Yes, there is a light at the horizon: you cannot FREE a dataset
> > >:>allocated in JCL. So this trick might well be the solution.
> > >
> > >You certainly can.
> > > 
> > What if he were to add a subsequent IEFBR14,COND=(0,LE) step
> > allocating the same DSN?
> > 
> > 
> > 
> > On Wed, 21 Dec 2011 19:23:47 +0200, Binyamin Dissen wrote:
> > >
> > >Curious as to why you wish to prevent it. If they can 
> > arbitrarily choose to
> > >logon to any system, why prevent concurrent logons?
> > > 
> > Think, "managers."  (Actually, I think his concern was synchronizing
> > profile updates.)
> > 
> > -- gil
> 
> Gee, I never saw a TSO logon proc with more than one step. 
> Never would have occurred to me.
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * 
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain 
> confidential or proprietary information. If you are not the 
> intended recipient, please contact the sender by reply e-mail 
> and destroy all copies of the original message. 
> HealthMarkets(r) is the brand name for products underwritten 
> and issued by the insurance subsidiaries of HealthMarkets, 
> Inc. -The Chesapeake Life Insurance Company(r), Mid-West 
> National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
>  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Wednesday, December 21, 2011 11:42 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO "concern" - sysplex multisystem logon.
> 
> On Wed, 21 Dec 2011 19:22:31 +0200, Binyamin Dissen wrote:
> 
> >On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM" wrote:
> >
> >:>Yes, there is a light at the horizon: you cannot FREE a dataset
> >:>allocated in JCL. So this trick might well be the solution.
> >
> >You certainly can.
> > 
> What if he were to add a subsequent IEFBR14,COND=(0,LE) step
> allocating the same DSN?
> 
> 
> 
> On Wed, 21 Dec 2011 19:23:47 +0200, Binyamin Dissen wrote:
> >
> >Curious as to why you wish to prevent it. If they can 
> arbitrarily choose to
> >logon to any system, why prevent concurrent logons?
> > 
> Think, "managers."  (Actually, I think his concern was synchronizing
> profile updates.)
> 
> -- gil

Gee, I never saw a TSO logon proc with more than one step. Never would have 
occurred to me.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Paul Gilmartin]

On Wed, 21 Dec 2011 19:22:31 +0200, Binyamin Dissen wrote:

>On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM" wrote:
>
>:>Yes, there is a light at the horizon: you cannot FREE a dataset
>:>allocated in JCL. So this trick might well be the solution.
>
>You certainly can.
> 
What if he were to add a subsequent IEFBR14,COND=(0,LE) step
allocating the same DSN?



On Wed, 21 Dec 2011 19:23:47 +0200, Binyamin Dissen wrote:
>
>Curious as to why you wish to prevent it. If they can arbitrarily choose to
>logon to any system, why prevent concurrent logons?
> 
Think, "managers."  (Actually, I think his concern was synchronizing
profile updates.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[McKown, John]

> 
> Curious as to why you wish to prevent it. If they can 
> arbitrarily choose to
> logon to any system, why prevent concurrent logons?
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel

Because my boss said so. He didn't say why. I don't argue any more. We are "CPU 
poor" and our programmer's generally are "gluttons". They use FileAid in TSO to 
edit and change __HUGE__ datasets, rather than write an ICETOOL batch job. They 
do it over, and over, and over. 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Paul Gilmartin]

On Wed, 21 Dec 2011 17:39:14 +0100, Vernooij, CP - SPLXM wrote:
>>
>> Any other ideas?
>> --
>> John McKown
>
>Yes, there is a light at the horizon: you cannot FREE a dataset
>allocated in JCL. So this trick might well be the solution.
> 
I thought I had done this routinely; now I must try it to prove
myself wrong.  But perhaps I FREEd the allocation but the ENQ
remains, which would satisfy John's need.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Binyamin Dissen]

On Wed, 21 Dec 2011 17:39:14 +0100 "Vernooij, CP - SPLXM"
 wrote:

:>Yes, there is a light at the horizon: you cannot FREE a dataset
:>allocated in JCL. So this trick might well be the solution.

You certainly can.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Binyamin Dissen]

On Wed, 21 Dec 2011 10:06:21 -0600 "McKown, John"
 wrote:

:>We are upgrading, finally, to z/OS 1.12 next month. One thing that I would 
like to do is allow certain people the ability to logon to TSO on all systems 
concurrently. It appears this is possible, for all users, simply by not 
propagating the SYSIKJUA enqueue via the GRSRNL. In fact, I have tested this 
and it works. I know about the ISPF "problem" and basically have risk accepted 
it. But my manager has thrown a wrench into the works. He likes the idea of us 
(Tech Services) and Production Control being able to do this. But he does not 
want any other TSO users to be able to do it. Well, I thought, use the new APPL 
support in TSO and just allow the other users READ access to the appropriate 
z/OS image. But that's not acceptable either. We need others to be able to 
logon to any system, but only on to one at a time. The only solution that I 
have figured out, so far, is to change the TSO logon PROC to allocate a user 
specific DSN with a DISP=(NEW,DELETE,DELETE). Perhaps something !
 li!
:> ke:
 
:>//@PROFILE DD DSN=&SYSUID..ISPF.PROFILE,
:>// DISP=(NEW,DELETE,DELETE),
:>// SPACE=(TRK,0),
:>// UNIT=SYSDA,VOL=REF=SYS1.MACLIB

:>I need to disguise the DD so that it does not "stand out" and looks 
"required". Of course, once someone figures this out, they will simply logon to 
SY1, do a FREE, then logon to SY2, and so on. It is, at best, a poor 
"solution". But if I don't come up with something, we will continue to 
progagate the SYSIKJUA enqueue, limiting everyone to a single logon. To add to 
the misery, I'm not allowed to write an exit, such as the IKJEFLD, because we 
have a policy against doing exits. Or much of anything in HLASM, due to 
maintenance fears.

:>Any other ideas?

Curious as to why you wish to prevent it. If they can arbitrarily choose to
logon to any system, why prevent concurrent logons?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Elardus Engelbrecht]

McKown, John wrote:

>He likes the idea of us (Tech Services) and Production Control being able to 
>do this. But he does not want any other TSO users to be able to do it. 

You can do that. We do this trick for many years.

First look at Mark Zelden's hints about this.

We use GRS only for our techies so they can logon at any LPAR concurrently. We 
also have one set of TSO proc for us techies and another for our 
bread-and-butter customers.

That one TSO proc for us techies uses a profile dataset name with an SMFID 
embedded, but the other TSO proc doesn't do that.

Also use LPAR specific procs to limit logons by just placing desired TSO proc 
in the correct library. Use RACF to limit the correct procs to the correct ids.

Best of all, please reread Mark Zelden's hints at his website about this topic.

HTH!

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Vernooij, CP - SPLXM]

"McKown, John"  wrote in message
news:.
..
> We are upgrading, finally, to z/OS 1.12 next month. One thing that I
would like to do is allow certain people the ability to logon to TSO on
all systems concurrently. It appears this is possible, for all users,
simply by not propagating the SYSIKJUA enqueue via the GRSRNL. In fact,
I have tested this and it works. I know about the ISPF "problem" and
basically have risk accepted it. But my manager has thrown a wrench into
the works. He likes the idea of us (Tech Services) and Production
Control being able to do this. But he does not want any other TSO users
to be able to do it. Well, I thought, use the new APPL support in TSO
and just allow the other users READ access to the appropriate z/OS
image. But that's not acceptable either. We need others to be able to
logon to any system, but only on to one at a time. The only solution
that I have figured out, so far, is to change the TSO logon PROC to
allocate a user specific DSN with a DISP=(NEW,DELETE,DELETE). Perhaps
something li!
>  ke:
>  
> //@PROFILE DD DSN=&SYSUID..ISPF.PROFILE,
> // DISP=(NEW,DELETE,DELETE),
> // SPACE=(TRK,0),
> // UNIT=SYSDA,VOL=REF=SYS1.MACLIB
> 
> I need to disguise the DD so that it does not "stand out" and looks
"required". Of course, once someone figures this out, they will simply
logon to SY1, do a FREE, then logon to SY2, and so on. It is, at best, a
poor "solution". But if I don't come up with something, we will continue
to progagate the SYSIKJUA enqueue, limiting everyone to a single logon.
To add to the misery, I'm not allowed to write an exit, such as the
IKJEFLD, because we have a policy against doing exits. Or much of
anything in HLASM, due to maintenance fears.
> 
> Any other ideas?
>  
> --
> John McKown 

Yes, there is a light at the horizon: you cannot FREE a dataset
allocated in JCL. So this trick might well be the solution.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[David Andrews]

On Wed, 2011-12-21 at 11:06 -0500, McKown, John wrote:
> allow certain people the ability to logon to TSO on all systems
> concurrently. It appears this is possible, for all users, simply by
> not propagating the SYSIKJUA enqueue via the GRSRNL.

The SYSIKJUA RNAME appears to be the TSO userid:

11.24.59   d grs,res=(sysikjua,*)  
11.24.59   ISG343I 11.24.59 GRS STATUS 499 
S=SYSTEM  SYSIKJUA DBA 
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS
PROD 0038   008FFB00 EXCLUSIVEOWN  

So could you specify your own (and other privileged ones) RNAME as an
RNL exclude?

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: TSO "concern" - sysplex multisystem logon.

[Mark Zelden]

On Wed, 21 Dec 2011 10:06:21 -0600, McKown, John 
 wrote:

>We are upgrading, finally, to z/OS 1.12 next month. One thing that I would 
>like to do is allow certain people the ability to logon to TSO on all systems 
>concurrently. It appears this is possible, for all users, simply by not 
>propagating the SYSIKJUA enqueue via the GRSRNL. In fact, I have tested this 
>and it works. I know about the ISPF "problem" and basically have risk accepted 
>it. But my manager has thrown a wrench into the works. He likes the idea of us 
>(Tech Services) and Production Control being able to do this. But he does not 
>want any other TSO users to be able to do it. Well, I thought, use the new 
>APPL support in TSO and just allow the other users READ access to the 
>appropriate z/OS image. But that's not acceptable either. We need others to be 
>able to logon to any system, but only on to one at a time. The only solution 
>that I have figured out, so far, is to change the TSO logon PROC to allocate a 
>user specific DSN with a DISP=(NEW,DELETE,DELETE). Perhaps something l!
 ike:
>
>//@PROFILE DD DSN=&SYSUID..ISPF.PROFILE,
>// DISP=(NEW,DELETE,DELETE),
>// SPACE=(TRK,0),
>// UNIT=SYSDA,VOL=REF=SYS1.MACLIB
>
>I need to disguise the DD so that it does not "stand out" and looks 
>"required". Of course, once someone figures this out, they will simply logon 
>to SY1, do a FREE, then logon to SY2, and so on. It is, at best, a poor 
>"solution". But if I don't come up with something, we will continue to 
>progagate the SYSIKJUA enqueue, limiting everyone to a single logon. To add to 
>the misery, I'm not allowed to write an exit, such as the IKJEFLD, because we 
>have a policy against doing exits. Or much of anything in HLASM, due to 
>maintenance fears.
>
>Any other ideas?
>
>--


I already mentioned what I did in a previous response.  Why a "disguised" data 
set 
like the one above.   Just allocate a non-system specific profile name as 
DISP=OLD 
(or SHR, but OLD would be better) for one set of users in the logon CLIST(s) or
LOGON proc, and specify a system specific one in another set.  Or if you really
want to use the shared profile support (which I also mentioned I thought was
a kludge), then DISP=SHR for those users and the single profile name and
DISP=OLD of the others you don't want to allow logging on.   Sure, they
could do the free on their ISPPROF dsn and re-allocate it as SHR, but
that is no different than using the method you described above and the
user wouldn't get very far without the profile data set.By not using the
profile sharing and only allocating the system specific profile data sets for
those you want to allow, you will have as much control as you want. 

I guess you could use automation - and assuming this is a sysplex use a
combination of "RO *ALL,D A,tsouser" to find out if they are already logged
onto another LPAR and cancel them.  This can get as specific as you want
in code for the users you want to allow this for, or work by userid pattern. 

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN