Re: Possible change to MCSOPER processing, further clarification

[W. Kevin Kelley]

On Tue, 11 Dec 2007 20:32:26 -0600, W. Kevin Kelley 
<[EMAIL PROTECTED]> wrote:

>There seems to be some confusion as to what these possible changes are 
>and why IBM is making them.
>
>The MCSOPER programming interface currently allows you to make a system
>console inactive via the REQUEST=DEACTIVATE parameter.
>Note: By system console, we mean the operating system console function
>provided by the Hardware Management Console (HMC).
>When a system console becomes inactive, there is no way for you to make it
>active again (except by reIPLing that system).
>The change will prevent the MCSOPER programming interface from
>inadvertently making a system console inactive.
>
>This should not be confused with the VARY CN,ACTIVATE and VARY
>CN,DEACTIVATE system commands.
>The VARY CN,ACTIVATE system command allows you to place the system
>console in problem determination mode.
>The VARY CN,DEACTIVATE system command allows you to take the system
>console out of problem determination mode.
>These system commands are NOT impacted by the change.
>

In addition, the MCSOPER programming interface will no longer allow you to 
make an inactive system console active via the REQUEST=ACTIVATE 
parameter.
Note: This function does not really reactivate the system console. That can 
only be done by the operating system. 
What this function does is make the inactive system console an active EMCS 
console that the operating system thinks is a system console. 
By disallowing the MCSOPER programming interface from making an inactive 
system console active, IBM is protecting the name of the system console from 
being used as an EMCS console. 
Since most installations have their system console name defined in their 
CONSOLxx parmlib member, this will ensure that the reIPLing of the system is 
successful in making the system console active again with the desired name. 
If you reuse the name to activate an EMCS console prior to reIPLing, a system 
console will be active but it will have a different name.
Note: If you do not want the console name to be associated with the system 
console anymore, you can remove its console definition via IEARELEC.

--
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: Possible change to MCSOPER processing

[W. Kevin Kelley]

There seems to be some confusion as to what these possible changes are and 
why IBM is making them.

The MCSOPER programming interface currently allows you to make a system 
console inactive via the REQUEST=DEACTIVATE parameter.
Note: By system console, we mean the operating system console function 
provided by the Hardware Management Console (HMC).
When a system console becomes inactive, there is no way for you to make it 
active again (except by reIPLing that system).
The change will prevent the MCSOPER programming interface from 
inadvertently making a system console inactive.

This should not be confused with the VARY CN,ACTIVATE and VARY 
CN,DEACTIVATE system commands.
The VARY CN,ACTIVATE system command allows you to place the system 
console in problem determination mode.
The VARY CN,DEACTIVATE system command allows you to take the system 
console out of problem determination mode.
These system commands are NOT impacted by the change.

--
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: Possible change to MCSOPER processing

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 12/06/2007
   at 09:35 PM, "W. Kevin Kelley" <[EMAIL PROTECTED]> said:

>We are contemplating making a change to MCSOPER processing to prevent 
>user's from specifying a console that has been defined as a system
>console.

Sounds good to me, assuming that you're just referring to the console id
used for the EMCS session.

>The intent of this change would be to further protect the 
>system console (the console of last resort) from being inadvertently
>activated  or deactivated.

Are you also going to prohibit a VARY command from having the HMC as a
target? If so, that would be a problem.
 
-- 
 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: Possible change to MCSOPER processing

[Skip Robinson]

I'm a little surprised at tone of the few responses here. So I'll just
reply to the original question.

1. Obviously this proposal is an attempt to solve a real customer problem.
At least one. Fix teams do not lounge in windowless rooms imagining
hypothetical problems that might be solved by dubious circumventions that
might or might not satisfy the customer(s) who suffered the problem(s) in
the first place.

2. I cannot myself imagine a situation in which activating SYSCONS by any
other means than V CN(*),ACT on the HMC would be a proper or clever or
remotely useful thing to do.

3. I appreciate Mr. Kelley's open proposal in this worldwide public forum.

4. Unless someone can offer a shred of evidence that this change might
actually be harmful in the current (never mind parallel) universe, I
suggest we bless it and move on to solving real problems that we ourselves
have experienced.

SHARE in Orlando would be an excellent venue for further discussion, if
further discussion is even warranted.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 "W. Kevin Kelley" 
 <[EMAIL PROTECTED] 
 NE.NET>To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU>         Possible change to MCSOPER  
       processing  
   
 12/06/2007 07:35  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




We are contemplating making a change to MCSOPER processing to prevent
user's from specifying a console that has been defined as a system console.

(By system console, we mean the operating system console facility available

through the HMC). The intent of this change would be to further protect the

system console (the console of last resort) from being inadvertently
activated
or deactivated.

Does anyone have a problem with this? If so, we'd like to hear from you.
You
can post here or contact me privately by e-mail [EMAIL PROTECTED]

W. Kevin Kelley  IBM POK Lab -- z/OS Core Technical Development

--
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: Possible change to MCSOPER processing

[Bruce Hewson]

Hello Kevin,

We are required to have LOGON REQUIRED on all consoles, including SYSCONS.
(HMC Operating System Messages). 

This allows us to IPL and reply to messages until RACF starts up and locks
up the console  until you sign in.but, tragically, there is no LOGON
command available via SYSCONS (not 3270).

Since we issue V CN(*),ACTIVATE to establish the SYSCONS, we are not able to
issue the DEACTIVATEsince by this time we are not logged in.

Maybe we could issue the DEACTIVATE via the process you are considering
removing.

Regards
Bruce Hewson

--
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: Possible change to MCSOPER processing

[Brian Westerman]

I have a problem with it.  

How would  you decide if the act/Deact was "inadvertent"?  What is the
danger that you are trying to protect us from?  I would imagine that being
authorized to act/deact ought to mean that you wanted to do it int he first
place.  Imagine what the consequences would be for someone who was
authorized to do it, and all of a sudden you were to decide that the
activate might be inadvertent.

If there were some real danger or exposure that isn't already covered by
normal controls, I'd like to know what it is so that we could better decide
if the change you are offering is really necessary and under what
circumstances. 

Brian

--
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

Possible change to MCSOPER processing

[W. Kevin Kelley]

We are contemplating making a change to MCSOPER processing to prevent 
user's from specifying a console that has been defined as a system console. 
(By system console, we mean the operating system console facility available 
through the HMC). The intent of this change would be to further protect the 
system console (the console of last resort) from being inadvertently activated 
or deactivated.

Does anyone have a problem with this? If so, we'd like to hear from you. You 
can post here or contact me privately by e-mail [EMAIL PROTECTED]

W. Kevin Kelley  IBM POK Lab -- z/OS Core Technical Development
 

--
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