Re: Ficon CTC's between LPAR's in same Box

[Jerry Whitteridge]

At least on z/OS (not sure under z/VM) you can use switch attached FC channels 
for CTC's as well as other purposes (so unlike Escon you don't have to dedicate 
a CNC and CTC port) as FC channels use the same definition at each end.

Jerry Whitteridge
Design Engineer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Monday, July 18, 2011 1:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Ficon CTC's between LPAR's in same Box

No HW required besides the two Ficon ports and a short cable.  At the SW side: 
configure them in the IOCP.
2011/7/18 Crispin Hugo mailto:crispin.h...@macro4.com>>
Is there a way I can configure CTC's between LPAR's in same physical box
without going out and buying hardware?

I saw somewhere that one could use share CHPID's with other devices
using TYPE=FC. Does this only work if going out to Ficon switch ?


I do have a Ficon express 8 card with 1 unused port, Can I do anything
with that ?

I do have a Ficon card with 2 currently unused ports port on it. Can
this be used to join the LPAR's together by cabling 1 port to the other.

All this is to create a z/VM 6.1 cse with 2 LPARs.

- 
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 internal virus protection system.
. 



--
Kris Buelens,
IBM Belgium, VM customer support

"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

Re: REXEC and RXAGENT1

[Tom Duerbusch]

OK, that makes sense to what I'm seeing now.

I never got into using OBEYFILE.
Back in the early '90s when VM first got IP, everytime I used OBEYFILE, I wiped 
out things that I didn't intend to.

Never went back to it again.

I never caught on to which groups of statements were considered "packets" of 
statements.  That is if you replaced one statement, the entire "packet" of 
statements were replaced.

Anyway, I'll get back to this after I schedule the cycle of TCPIP.

Thanks

Tom Duerbusch
THD Consulting

>>> Kris Buelens  7/18/2011 3:33 PM >>>
Alan explained here a while ago that you can use OBEYFILE to make TCPIP
restart servers after that they have been taken from the restart list due to
too frequent restarts.

2011/7/18 Tom Duerbusch 

> When I reread Step 2
> Yep, it does say a "list of tags", it's not meant to be a sample entry.
>
> Now, I'm getting somewhere...
>
> I copied the entries from the IBM DTCPARMS.
>
> Now, things are being tried, at least.
>
>15:14:43 AUTO LOGON  ***   REXECD   USERS = 62BY TCPMAINT
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS
> PENDING
>15:14:43 USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY
> TCPIP
> TCPIP   USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY TCPIP
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS
> PENDING
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT2 ISSUED BY REXECD; RESULTS
> PENDING
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT2 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
>
>15:15:14 AUTO LOGON  ***   RXAGENT1 USERS = 62BY REXECD
>15:15:14 USER DSC   LOGOFF AS  REXECD   USERS = 61
>
> What is now strange, is that I have to (x)autolog REXECD after I force it.
>  REXECD was being detected that it was down and autologed by TCPIP.  Now I
> have to do it.
> Also, after it autologs RXAGENT1, REXECD automatically logs off.
>
> I'll have TCPIP scheduled to be cycled and try this stuff again on
> Wednesday.
>
> My parms now look like:
>
> :nick.REXECD:type.server  :class.rexec
> :nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD
>
> .*==
> .* Anonymous Remote Execution (REXEC) and Remote Shell (RSH) agents
> .*--
> :nick.rexec_agent
>  :type.class
>  :name.Anonymous Remote Execution agent
>  :command.RXSNDIU
>  :runtime.C
>
>
> :Nick.REXECD:Type.Server:Class.rexec
>  :Parms.
>  :Anonymous.YES
>  :ESM_Enable.
>  :ESM_Validate.
>
> :nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD
>
> :Nick.RXAGENT2   :type.server  :class.rexec_agent
>   :For.REXECD
>
> Tom Duerbusch
> THD Consulting
>
>
> >>> Scott Rohling  7/15/2011 7:29 PM >>>
> Well - I dug a bit deeper - looked at TCPRUN EXEC, etc..:type. and
> .class do seem to be required to modify server entries.   In fact - the
> section in TCPIP Planning and Admin section on 'Customizing Servers' shows
> several examples all specify :type and :class.
>
> I think where we both were confused is in Step 2 of 'Configuring the REXEC
> Server'..  it shows what looks like a :nickname entry, but is actually a
> list of tags that are recognized for REXEC.  To modify those tags, you
> still
> need to create an entry using :nick, :type, and :class.
>
> So - not a bug..  maybe a candidate for a reader comment?  It's spelled out
> in the 'DTCPARMS File Format' section that:
>
> Every entry must include either a :Type.Server or a :Type.Class definition.
>
> Entries that define a server using a :Type.Server definition must also
> include a :Class. tag and value to identify the class to which that server
> belongs.
>
> It certainly slipped by me though in looking at your DTCPARMS entry!
>
> Scott Rohling
> On Fri, Jul 15, 2011 at 5:01 PM, Scott Rohling  >wrote:
>
> > Hmmph..  we didn't have REXECD enabled on my test system -- so I did so
> ..
> > and added the :nick.REXECD tag with Anonymous.YES to SYSTEM DTCPARMS.
> >
> > What I see on a debug is much like yours - but also with this:
> >
> > +++ Lookup_Details.OUT
> >   $ParmFile_Serve = IBM DTCPARMS E1
> >   $ParmFile_Class = IBM DTCPARMS E1
> > +++ Lookup_Details.OUT
> >   $ParmFile_Serve = IBM DTCPARMS E1
> >   $ParmFile_Class = IBM DTCPARMS E1
> >
> > Like you - my SYSTEM DTCPARMS is on D..  so it doesn't appear it's using
> > it.
> >
> >
> > The NAME SEARCH debug info got me thinking..   So I did this in my SYSTEM
> > DTCPARMS:
> >
> > :Nick.REXECD :Type.Server :Class.rexec
> >  :Parms.-d
> >  :Anonymous.YES
> >  :ESM_Enable.
> >  :ESM_Validate.
> >
> > Note that I added :Type.Server and :class.rexec
> >
> > Once I did this -- voila --  it found my entry in SYSTEM DTCPARMS,

Re: Ficon CTC's between LPAR's in same Box

[Kris Buelens]

No HW required besides the two Ficon ports and a short cable.  At the SW
side: configure them in the IOCP.

2011/7/18 Crispin Hugo 

> Is there a way I can configure CTC's between LPAR's in same physical box
> without going out and buying hardware?
>
> I saw somewhere that one could use share CHPID's with other devices
> using TYPE=FC. Does this only work if going out to Ficon switch ?
>
>
> I do have a Ficon express 8 card with 1 unused port, Can I do anything
> with that ?
>
> I do have a Ficon card with 2 currently unused ports port on it. Can
> this be used to join the LPAR's together by cabling 1 port to the other.
>
> All this is to create a z/VM 6.1 cse with 2 LPARs.
>
> - 
> This email has been scanned for all known viruses by the MessageLabs Email
> Security Service and the Macro 4 internal virus protection system.
> . 




-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: REXEC and RXAGENT1

[Kris Buelens]

Alan explained here a while ago that you can use OBEYFILE to make TCPIP
restart servers after that they have been taken from the restart list due to
too frequent restarts.

2011/7/18 Tom Duerbusch 

> When I reread Step 2
> Yep, it does say a "list of tags", it's not meant to be a sample entry.
>
> Now, I'm getting somewhere...
>
> I copied the entries from the IBM DTCPARMS.
>
> Now, things are being tried, at least.
>
>15:14:43 AUTO LOGON  ***   REXECD   USERS = 62BY TCPMAINT
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS
> PENDING
>15:14:43 USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY
> TCPIP
> TCPIP   USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY TCPIP
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS
> PENDING
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
> TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT2 ISSUED BY REXECD; RESULTS
> PENDING
> TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT2 ISSUED BY REXECD; COMMAND
> SUCCESSFUL
>
>15:15:14 AUTO LOGON  ***   RXAGENT1 USERS = 62BY REXECD
>15:15:14 USER DSC   LOGOFF AS  REXECD   USERS = 61
>
> What is now strange, is that I have to (x)autolog REXECD after I force it.
>  REXECD was being detected that it was down and autologed by TCPIP.  Now I
> have to do it.
> Also, after it autologs RXAGENT1, REXECD automatically logs off.
>
> I'll have TCPIP scheduled to be cycled and try this stuff again on
> Wednesday.
>
> My parms now look like:
>
> :nick.REXECD:type.server  :class.rexec
> :nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD
>
> .*==
> .* Anonymous Remote Execution (REXEC) and Remote Shell (RSH) agents
> .*--
> :nick.rexec_agent
>  :type.class
>  :name.Anonymous Remote Execution agent
>  :command.RXSNDIU
>  :runtime.C
>
>
> :Nick.REXECD:Type.Server:Class.rexec
>  :Parms.
>  :Anonymous.YES
>  :ESM_Enable.
>  :ESM_Validate.
>
> :nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD
>
> :Nick.RXAGENT2   :type.server  :class.rexec_agent
>   :For.REXECD
>
> Tom Duerbusch
> THD Consulting
>
>
> >>> Scott Rohling  7/15/2011 7:29 PM >>>
> Well - I dug a bit deeper - looked at TCPRUN EXEC, etc..:type. and
> .class do seem to be required to modify server entries.   In fact - the
> section in TCPIP Planning and Admin section on 'Customizing Servers' shows
> several examples all specify :type and :class.
>
> I think where we both were confused is in Step 2 of 'Configuring the REXEC
> Server'..  it shows what looks like a :nickname entry, but is actually a
> list of tags that are recognized for REXEC.  To modify those tags, you
> still
> need to create an entry using :nick, :type, and :class.
>
> So - not a bug..  maybe a candidate for a reader comment?  It's spelled out
> in the 'DTCPARMS File Format' section that:
>
> Every entry must include either a :Type.Server or a :Type.Class definition.
>
> Entries that define a server using a :Type.Server definition must also
> include a :Class. tag and value to identify the class to which that server
> belongs.
>
> It certainly slipped by me though in looking at your DTCPARMS entry!
>
> Scott Rohling
> On Fri, Jul 15, 2011 at 5:01 PM, Scott Rohling  >wrote:
>
> > Hmmph..  we didn't have REXECD enabled on my test system -- so I did so
> ..
> > and added the :nick.REXECD tag with Anonymous.YES to SYSTEM DTCPARMS.
> >
> > What I see on a debug is much like yours - but also with this:
> >
> > +++ Lookup_Details.OUT
> >   $ParmFile_Serve = IBM DTCPARMS E1
> >   $ParmFile_Class = IBM DTCPARMS E1
> > +++ Lookup_Details.OUT
> >   $ParmFile_Serve = IBM DTCPARMS E1
> >   $ParmFile_Class = IBM DTCPARMS E1
> >
> > Like you - my SYSTEM DTCPARMS is on D..  so it doesn't appear it's using
> > it.
> >
> >
> > The NAME SEARCH debug info got me thinking..   So I did this in my SYSTEM
> > DTCPARMS:
> >
> > :Nick.REXECD :Type.Server :Class.rexec
> >  :Parms.-d
> >  :Anonymous.YES
> >  :ESM_Enable.
> >  :ESM_Validate.
> >
> > Note that I added :Type.Server and :class.rexec
> >
> > Once I did this -- voila --  it found my entry in SYSTEM DTCPARMS,
> started
> > up RXAGENT1 and was happy.  Even the -d parm was honored and I get more
> > debug info from rexec itself.
> >
> > So - this looks like  bug - either doc or code...but try changing
> your
> > :Nick.REXECD to include type and class.
> >
> > The NAMES file search seems to be looking for both the nickname AND the
> > Type tag.   To specify :type - you also have to specify :class.I'm
> > guessing it should be searching on just :Nick.. and this is a workaround.
> >
> > Hope this helps.. please open a PMR!
> >
> > Scott Rohling
> >

Ficon CTC's between LPAR's in same Box

[Crispin Hugo]

Is there a way I can configure CTC's between LPAR's in same physical box
without going out and buying hardware?

I saw somewhere that one could use share CHPID's with other devices
using TYPE=FC. Does this only work if going out to Ficon switch ?


I do have a Ficon express 8 card with 1 unused port, Can I do anything
with that ?

I do have a Ficon card with 2 currently unused ports port on it. Can
this be used to join the LPAR's together by cabling 1 port to the other.

All this is to create a z/VM 6.1 cse with 2 LPARs.

- 
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 internal virus protection system.
. 

Re: REXEC and RXAGENT1

[Tom Duerbusch]

When I reread Step 2
Yep, it does say a "list of tags", it's not meant to be a sample entry.

Now, I'm getting somewhere...

I copied the entries from the IBM DTCPARMS.

Now, things are being tried, at least.

15:14:43 AUTO LOGON  ***   REXECD   USERS = 62BY TCPMAINT   
 
TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS PENDING 
 
15:14:43 USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY TCPIP   
 
TCPIP   USER DSC   LOGOFF AS  RXAGENT1 USERS = 61FORCED BY TCPIP
 
TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND 
SUCCESSFUL   
TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT1 ISSUED BY REXECD; RESULTS PENDING 
 
TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT1 ISSUED BY REXECD; COMMAND 
SUCCESSFUL   
TCPIP   15:14:43 DTCMON442I CP FORCE RXAGENT2 ISSUED BY REXECD; RESULTS PENDING 
 
TCPIP   15:14:43 DTCMON443I CP FORCE RXAGENT2 ISSUED BY REXECD; COMMAND 
SUCCESSFUL   

15:15:14 AUTO LOGON  ***   RXAGENT1 USERS = 62BY REXECD
15:15:14 USER DSC   LOGOFF AS  REXECD   USERS = 61 

What is now strange, is that I have to (x)autolog REXECD after I force it.  
REXECD was being detected that it was down and autologed by TCPIP.  Now I have 
to do it.
Also, after it autologs RXAGENT1, REXECD automatically logs off.

I'll have TCPIP scheduled to be cycled and try this stuff again on Wednesday.

My parms now look like:

:nick.REXECD:type.server  :class.rexec 
:nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD 
   
.*==
.* Anonymous Remote Execution (REXEC) and Remote Shell (RSH) agents 
.*--
:nick.rexec_agent   
  :type.class   
  :name.Anonymous Remote Execution agent
  :command.RXSNDIU  
  :runtime.C


:Nick.REXECD:Type.Server:Class.rexec
  :Parms.   
  :Anonymous.YES
  :ESM_Enable.  
  :ESM_Validate.

:nick.RXAGENT1  :type.server  :class.rexec_agent   :for.REXECD  

:Nick.RXAGENT2   :type.server  :class.rexec_agent   
   :For.REXECD  

Tom Duerbusch
THD Consulting


>>> Scott Rohling  7/15/2011 7:29 PM >>>
Well - I dug a bit deeper - looked at TCPRUN EXEC, etc..:type. and
.class do seem to be required to modify server entries.   In fact - the
section in TCPIP Planning and Admin section on 'Customizing Servers' shows
several examples all specify :type and :class.

I think where we both were confused is in Step 2 of 'Configuring the REXEC
Server'..  it shows what looks like a :nickname entry, but is actually a
list of tags that are recognized for REXEC.  To modify those tags, you still
need to create an entry using :nick, :type, and :class.

So - not a bug..  maybe a candidate for a reader comment?  It's spelled out
in the 'DTCPARMS File Format' section that:

Every entry must include either a :Type.Server or a :Type.Class definition.

Entries that define a server using a :Type.Server definition must also
include a :Class. tag and value to identify the class to which that server
belongs.

It certainly slipped by me though in looking at your DTCPARMS entry!

Scott Rohling
On Fri, Jul 15, 2011 at 5:01 PM, Scott Rohling wrote:

> Hmmph..  we didn't have REXECD enabled on my test system -- so I did so ..
> and added the :nick.REXECD tag with Anonymous.YES to SYSTEM DTCPARMS.
>
> What I see on a debug is much like yours - but also with this:
>
> +++ Lookup_Details.OUT
>   $ParmFile_Serve = IBM DTCPARMS E1
>   $ParmFile_Class = IBM DTCPARMS E1
> +++ Lookup_Details.OUT
>   $ParmFile_Serve = IBM DTCPARMS E1
>   $ParmFile_Class = IBM DTCPARMS E1
>
> Like you - my SYSTEM DTCPARMS is on D..  so it doesn't appear it's using
> it.
>
>
> The NAME SEARCH debug info got me thinking..   So I did this in my SYSTEM
> DTCPARMS:
>
> :Nick.REXECD :Type.Server :Class.rexec
>  :Parms.-d
>  :Anonymous.YES
>  :ESM_Enable.
>  :ESM_Validate.
>
> Note that I added :Typ

Re: Behaviour after restart

[Mike Walter]

I held no expectation, merely asked a question.  As described in earlier posts 
after Wolfgang reported it, and as with you, I never noticed the difference 
before, either.

Since it has not affected us I'm not inclined to invest my time to report it, 
nor IBM's time in devising a less inexplicable and consistent response from a 
SHUTDOWN REIPL (which are by far our most frequent forms of IPL).

But "anyone else" affected [ahem Wolfgang :-) ] is welcome to make their 
business case to IBM, further improving the already sterling z/VM reputation 
for clarity and consistency.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Alan Altmark
Sent: Monday, July 18, 2011 1:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Behaviour after restart

On Monday, 07/18/2011 at 02:19 EDT, Mike Walter 
 wrote:

> Thanks for the explanation.  Could one have a reasonable expectation 
that in 
> the z/VM release "6.next", SHUTDOWN REIPL might be updated to handle 
'TERMINAL 
> HOLD OFF' in the same fashion as it was handled at the previous 
non-'REIPL', or 
> perhaps have a more clearly-defined (less "inexplicable") action in 
SYSTEM 
> CONFIG?

No one has reported this behavior as a potential bug, so your expectation 
is somewhat optimistic.   Until today, I never even noticed the difference 
since I don't do any automated SHUTDOWN REIPLs and pressing PA2 is part of 
my DNA.

If anyone feels that the current behavior is causing them difficulties, 
then please contact the Support Center to discuss.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: Behaviour after restart

[Alan Altmark]

On Monday, 07/18/2011 at 02:19 EDT, Mike Walter 
 wrote:

> Thanks for the explanation.  Could one have a reasonable expectation 
that in 
> the z/VM release "6.next", SHUTDOWN REIPL might be updated to handle 
'TERMINAL 
> HOLD OFF' in the same fashion as it was handled at the previous 
non-'REIPL', or 
> perhaps have a more clearly-defined (less "inexplicable") action in 
SYSTEM 
> CONFIG?

No one has reported this behavior as a potential bug, so your expectation 
is somewhat optimistic.   Until today, I never even noticed the difference 
since I don't do any automated SHUTDOWN REIPLs and pressing PA2 is part of 
my DNA.

If anyone feels that the current behavior is causing them difficulties, 
then please contact the Support Center to discuss.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: Behaviour after restart

[Mike Walter]

Alan,

Thanks for the explanation.  Could one have a reasonable expectation that in 
the z/VM release "6.next", SHUTDOWN REIPL might be updated to handle 'TERMINAL 
HOLD OFF' in the same fashion as it was handled at the previous non-'REIPL', or 
perhaps have a more clearly-defined (less "inexplicable") action in SYSTEM 
CONFIG?

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Alan Altmark
Sent: Monday, July 18, 2011 1:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Behaviour after restart

On Monday, 07/18/2011 at 12:50 EDT, Jim Bohnsack  
wrote:
> I saw the same, or a similar problem a couple of years ago.  It had
> something to do with the terminal emulator I was using.  I had the
> problem with Vista emulator from Tom Brennan Software.  Switching to a
> different emulator for the 2nd level system cured it and after
> installing an RSU or something, the problem went away and I could go
> back to Vista.

On a normal IPL, if the system is coming up warm (e.g. AUTO_WARM_IPL) 
without the PROMPT override, then the system operator will be TERMINAL 
HOLD OFF.  On a SHUTDOWN REIPL, the operator (inexplicably) comes up 
TERMINAL HOLD ON.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: Behaviour after restart

[Alan Altmark]

On Monday, 07/18/2011 at 12:50 EDT, Jim Bohnsack  
wrote:
> I saw the same, or a similar problem a couple of years ago.  It had
> something to do with the terminal emulator I was using.  I had the
> problem with Vista emulator from Tom Brennan Software.  Switching to a
> different emulator for the 2nd level system cured it and after
> installing an RSU or something, the problem went away and I could go
> back to Vista.

On a normal IPL, if the system is coming up warm (e.g. AUTO_WARM_IPL) 
without the PROMPT override, then the system operator will be TERMINAL 
HOLD OFF.  On a SHUTDOWN REIPL, the operator (inexplicably) comes up 
TERMINAL HOLD ON.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: Behaviour after restart

[Jim Bohnsack]

I saw the same, or a similar problem a couple of years ago.  It had 
something to do with the terminal emulator I was using.  I had the 
problem with Vista emulator from Tom Brennan Software.  Switching to a 
different emulator for the 2nd level system cured it and after 
installing an RSU or something, the problem went away and I could go 
back to Vista.


Sorry, but I don't remember any details about the problem.

Jim

On 7/18/2011 12:14 PM, Mike Walter wrote:

Wolfgang,

That certainly helps! =20
Counting the number of lines, I see that your OPERATOR goes into HOLDING at=
  the 30th displayed line:
   17:19:36 HCPIOP952I 0064M system storage  =20

Meanwhile, our OPERATOR continues on without HOLDING where the 36th message=
  at logon (last night) was:
   20:27:39 HCPIOP952I 15488M system storage=
   =20

I'm guessing that on your system, the OPERATOR virtual machine had logged o=
n, but there was a timing "race" between the IPL messages being issued, and=
  OPERATOR's "COMMAND" statement being processed as the virtual machine was =
being built and connected.

But then why does our OPERATOR consistently IPL (every week) without droppi=
ng into HOLDING? =20

Perhaps, just perhaps, it is because we being up OPERATOR on a model 4 term=
inal (42 lines x 80 wide).  That may be permitting the 36+ lines to display=
  before the PROFILE EXEC on our OPERATOR execute the command:
   'CP TERMINAL MORE 15 0 HOLD OFF'
Note: that is not present in the directory as a COMMAND statement.  Our OPE=
RATOR's directory COMMAND statements contain only:
   COMMAND SPOOL CONSOLE * CLASS C START NAME OPERATOR CONSOLE=20
   COMMAND SET SYSOPER *  =20

Can you try again with a model 4 terminal for OPERATOR?  There may be other=
  ways to resolve this, but again, it can't hurt until a better solution is =
devised.

It might be worth opening a PMR with IBM requesting a means in SYSTEM CONFI=
G to force the IPL console into "TERMINAL HOLD OFF MORE n n" immediately, e=
ven before OPERATOR logs on.

Could this be a 2nd level system?  That could present a whole different set=
  of circumstances.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.







-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Beh=
alf Of Buettner, Wolfgang
Sent: Monday, July 18, 2011 10:26 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Behaviour after restart

Mike,

I have changed the COMMAND TERM statement as suggested ... unfortunately no=
thing has changed.

Meanwhile, our system


Here is that screen in question:

  17:19:33 z/VM SYSTEM RESTART FROM SHUTDOWN REIPL  =
 =20
  17:19:33 z/VM  V6 R1.0  SERVICE LEVEL 1003 (64-BIT)   =
 =20
  17:19:33 SYSTEM NUCLEUS CREATED ON 2011-07-15 AT 17:54:28, LOADED FROM VZG=
61R =20
17:19:33   =
 =20
17:19:33   =
 =20
17:19:33 * LICENSED MATERIALS - PROPERTY OF IBM**  =
 =20
17:19:33 *  *  =
 =20
17:19:33 * 5741-A07 (C) COPYRIGHT IBM CORP. 1983, 2009. ALL RIGHTS  *  =
 =20
17:19:33 * RESERVED. US GOVERNMENT USERS RESTRICTED RIGHTS - USE,   *  =
 =20
17:19:33 * DUPLICATION OR DISCLOSURE RESTRICTED BY GSA ADP SCHEDULE *  =
 =20
17:19:33 * CONTRACT WITH IBM CORP.  *  =
 =20
17:19:33 *  *  =
 =20
17:19:33 * * TRADEMARK OF INTERNATIONAL BUSINESS MACHINES.  *  =
 =20
17:19:33   =
 =20
17:19:33   =
 =20
  17:19:33 HCPZCO6718I Using parm disk 1 on volume VZG61R (device 5364).=
 =20
  17:19:33 HCPZCO6718I Parm disk resides on cylinders 39 through 158.   =
 =20
17:19:33 The directory on volume VZG61R at address 5364 has been brought on=
line.
  17:19:35 HCPWRS2513I  =
 =20
  17:19:35 HCPWRS2513I Spool files available  575   =
 =20
  17:19:36 HCPWRS2512I Spooling initialization is complete. =
 =20
17:19:36 DASD 5139 dump unit CP IPL pages 7696 =
 =20
17:19:36 HCPAAU2700I System gateway DAEZ identified.   =
 =20
17:19:36 z/VM Version 6 Release 1.0, Service Level 1003 (64-bit),  =
 =20
17:19:36 built on IBM Virtualization Technology=
 =20
17:19:36 There is no logmsg data   =
 =20
17:19:36 FILES: 0044 RDR, 0040 PRT,   NO PUN   =
 =20
17:

Re: Behaviour after restart

[Hodge, Robert L]

Have you tried placing the TERM HOLD OFF in a COMMAND record in the CP 
directory entry for OPERATOR? That way it is in effect when OPERATOR starts, 
not having to wait for the PROFILE EXEC to run.

Re: Behaviour after restart

[Mike Walter]

Wolfgang,

That certainly helps!  
Counting the number of lines, I see that your OPERATOR goes into HOLDING at the 
30th displayed line:
  17:19:36 HCPIOP952I 0064M system storage   

Meanwhile, our OPERATOR continues on without HOLDING where the 36th message at 
logon (last night) was:
  20:27:39 HCPIOP952I 15488M system storage 
  

I'm guessing that on your system, the OPERATOR virtual machine had logged on, 
but there was a timing "race" between the IPL messages being issued, and 
OPERATOR's "COMMAND" statement being processed as the virtual machine was being 
built and connected.

But then why does our OPERATOR consistently IPL (every week) without dropping 
into HOLDING?  

Perhaps, just perhaps, it is because we being up OPERATOR on a model 4 terminal 
(42 lines x 80 wide).  That may be permitting the 36+ lines to display before 
the PROFILE EXEC on our OPERATOR execute the command:
  'CP TERMINAL MORE 15 0 HOLD OFF'
Note: that is not present in the directory as a COMMAND statement.  Our 
OPERATOR's directory COMMAND statements contain only:
  COMMAND SPOOL CONSOLE * CLASS C START NAME OPERATOR CONSOLE 
  COMMAND SET SYSOPER *   

Can you try again with a model 4 terminal for OPERATOR?  There may be other 
ways to resolve this, but again, it can't hurt until a better solution is 
devised.

It might be worth opening a PMR with IBM requesting a means in SYSTEM CONFIG to 
force the IPL console into "TERMINAL HOLD OFF MORE n n" immediately, even 
before OPERATOR logs on.

Could this be a 2nd level system?  That could present a whole different set of 
circumstances.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.







-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Buettner, Wolfgang
Sent: Monday, July 18, 2011 10:26 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Behaviour after restart

Mike,

I have changed the COMMAND TERM statement as suggested ... unfortunately 
nothing has changed.

Meanwhile, our system


Here is that screen in question:

 17:19:33 z/VM SYSTEM RESTART FROM SHUTDOWN REIPL   
 17:19:33 z/VM  V6 R1.0  SERVICE LEVEL 1003 (64-BIT)
 17:19:33 SYSTEM NUCLEUS CREATED ON 2011-07-15 AT 17:54:28, LOADED FROM VZG61R  
17:19:33
17:19:33    
17:19:33 * LICENSED MATERIALS - PROPERTY OF IBM**   
17:19:33 *  *   
17:19:33 * 5741-A07 (C) COPYRIGHT IBM CORP. 1983, 2009. ALL RIGHTS  *   
17:19:33 * RESERVED. US GOVERNMENT USERS RESTRICTED RIGHTS - USE,   *   
17:19:33 * DUPLICATION OR DISCLOSURE RESTRICTED BY GSA ADP SCHEDULE *   
17:19:33 * CONTRACT WITH IBM CORP.  *   
17:19:33 *  *   
17:19:33 * * TRADEMARK OF INTERNATIONAL BUSINESS MACHINES.  *   
17:19:33    
17:19:33
 17:19:33 HCPZCO6718I Using parm disk 1 on volume VZG61R (device 5364). 
 17:19:33 HCPZCO6718I Parm disk resides on cylinders 39 through 158.
17:19:33 The directory on volume VZG61R at address 5364 has been brought online.
 17:19:35 HCPWRS2513I   
 17:19:35 HCPWRS2513I Spool files available  575
 17:19:36 HCPWRS2512I Spooling initialization is complete.  
17:19:36 DASD 5139 dump unit CP IPL pages 7696  
17:19:36 HCPAAU2700I System gateway DAEZ identified.
17:19:36 z/VM Version 6 Release 1.0, Service Level 1003 (64-bit),   
17:19:36 built on IBM Virtualization Technology 
17:19:36 There is no logmsg data
17:19:36 FILES: 0044 RDR, 0040 PRT,   NO PUN
17:19:36 LOGON AT 17:19:36 CES MONDAY 07/18/11  
17:19:36 GRAF  0009 LOGON  AS  OPERATOR USERS = 1   
17:19:36 HCPIOP952I 0064M system storage

HOLDING   DAEZ  

The indented lines above appear highlighted on the screen.

Wolfgang

  

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.

Re: Behaviour after restart

[Tom Paul]

Hi,

 

It looks like it’s 2nd level system.  So, your first level system need to be
change to fill in 2nd level.  Plz. Correct me if I am wrong. 

 

Warm Regards,

Tom

1-646-452-3359

 

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Buettner, Wolfgang
Sent: Monday, July 18, 2011 10:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Behaviour after restart

 

After a system restart OPERATOR's console hangs on its very first screen in
HOLDING status (I guess due to the fact that some system messages are
highlighted) and is waiting until the screen is cleared manually. Though
there is not any other prompt to be answered and the system itself continues
to start-up, that HOLDING seems to prevent OPERATOR from loading CMS and/or
starting its profile and other automatic processes immediately after the
virtual machine OPERATOR was started by system.

 

It appears it's not yet the turn of "COMMAND TERM HOLD OFF" which is defined
in the CP Directory.

 

So, is there a CONFIG statement or anything else to manage that?

 

Thank you,

Wolfgang Buettner

 


Software AG – Group Executive Board: Karl-Heinz Streibich
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr.
Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev 

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, –
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/
Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David
Broadbent, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/
Chairman of the Supervisory Board: Dr. Andreas Bereczky -
 http://www.softwareag.com 

 

Re: Behaviour after restart

[Buettner, Wolfgang]

Mike,

I have changed the COMMAND TERM statement as suggested ... unfortunately 
nothing has changed.

Here is that screen in question:

 17:19:33 z/VM SYSTEM RESTART FROM SHUTDOWN REIPL   
 17:19:33 z/VM  V6 R1.0  SERVICE LEVEL 1003 (64-BIT)
 17:19:33 SYSTEM NUCLEUS CREATED ON 2011-07-15 AT 17:54:28, LOADED FROM VZG61R  
17:19:33
17:19:33    
17:19:33 * LICENSED MATERIALS - PROPERTY OF IBM**   
17:19:33 *  *   
17:19:33 * 5741-A07 (C) COPYRIGHT IBM CORP. 1983, 2009. ALL RIGHTS  *   
17:19:33 * RESERVED. US GOVERNMENT USERS RESTRICTED RIGHTS - USE,   *   
17:19:33 * DUPLICATION OR DISCLOSURE RESTRICTED BY GSA ADP SCHEDULE *   
17:19:33 * CONTRACT WITH IBM CORP.  *   
17:19:33 *  *   
17:19:33 * * TRADEMARK OF INTERNATIONAL BUSINESS MACHINES.  *   
17:19:33    
17:19:33
 17:19:33 HCPZCO6718I Using parm disk 1 on volume VZG61R (device 5364). 
 17:19:33 HCPZCO6718I Parm disk resides on cylinders 39 through 158.
17:19:33 The directory on volume VZG61R at address 5364 has been brought online.
 17:19:35 HCPWRS2513I   
 17:19:35 HCPWRS2513I Spool files available  575
 17:19:36 HCPWRS2512I Spooling initialization is complete.  
17:19:36 DASD 5139 dump unit CP IPL pages 7696  
17:19:36 HCPAAU2700I System gateway DAEZ identified.
17:19:36 z/VM Version 6 Release 1.0, Service Level 1003 (64-bit),   
17:19:36 built on IBM Virtualization Technology 
17:19:36 There is no logmsg data
17:19:36 FILES: 0044 RDR, 0040 PRT,   NO PUN
17:19:36 LOGON AT 17:19:36 CES MONDAY 07/18/11  
17:19:36 GRAF  0009 LOGON  AS  OPERATOR USERS = 1   
17:19:36 HCPIOP952I 0064M system storage

HOLDING   DAEZ  

The indented lines above appear highlighted on the screen.

Wolfgang

  

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Mike Walter
Sent: Monday, July 18, 2011 5:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Behaviour after restart

Wolfgang,

Can you copy/paste the held screen so that we have a better idea of which 
messages might be causing the problem?

Could you change the CP directory entry's "COMMAND TERM HOLD OFF" to be 
"COMMAND TERM HOLD OFF MORE 0 0"? 
Then, in the OPERATOR's PROFILE EXEC change it to "CP TERM MORE n n" with more 
appropriate "MORE" times?  

It's worth a try until we better understand the root cause.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.


From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Buettner, Wolfgang
Sent: Monday, July 18, 2011 9:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Behaviour after restart

After a system restart OPERATOR's console hangs on its very first screen in 
HOLDING status (I guess due to the fact that some system messages are 
highlighted) and is waiting until the screen is cleared manually. Though there 
is not any other prompt to be answered and the system itself continues to 
start-up, that HOLDING seems to prevent OPERATOR from loading CMS and/or 
starting its profile and other automatic processes immediately after the 
virtual machine OPERATOR was started by system.
 
It appears it's not yet the turn of "COMMAND TERM HOLD OFF" which is 
defined in the CP Directory.
 
So, is there a CONFIG statement or anything else to manage that?
 
Thank you,
Wolfgang Buettner

Software AG - Group Executive Board: Karl-Heinz Streibich 
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr. 
Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev 

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, - 
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management 
Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. 
Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of t

Re: Behaviour after restart

[Mike Walter]

Wolfgang,

Can you copy/paste the held screen so that we have a better idea of which 
messages might be causing the problem?

Could you change the CP directory entry's "COMMAND TERM HOLD OFF" to be 
"COMMAND TERM HOLD OFF MORE 0 0"? 
Then, in the OPERATOR's PROFILE EXEC change it to "CP TERM MORE n n" with more 
appropriate "MORE" times?  

It's worth a try until we better understand the root cause.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.


From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Buettner, Wolfgang
Sent: Monday, July 18, 2011 9:54 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Behaviour after restart

After a system restart OPERATOR's console hangs on its very first screen in 
HOLDING status (I guess due to the fact that some system messages are 
highlighted) and is waiting until the screen is cleared manually. Though there 
is not any other prompt to be answered and the system itself continues to 
start-up, that HOLDING seems to prevent OPERATOR from loading CMS and/or 
starting its profile and other automatic processes immediately after the 
virtual machine OPERATOR was started by system.
 
It appears it's not yet the turn of "COMMAND TERM HOLD OFF" which is 
defined in the CP Directory.
 
So, is there a CONFIG statement or anything else to manage that?
 
Thank you,
Wolfgang Buettner

Software AG - Group Executive Board: Karl-Heinz Streibich 
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr. 
Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev 

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, - 
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management 
Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. 
Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the 
Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com 

Behaviour after restart

[Buettner, Wolfgang]

After a system restart OPERATOR's console hangs on its very first screen
in HOLDING status (I guess due to the fact that some system messages are
highlighted) and is waiting until the screen is cleared manually. Though
there is not any other prompt to be answered and the system itself
continues to start-up, that HOLDING seems to prevent OPERATOR from
loading CMS and/or starting its profile and other automatic processes
immediately after the virtual machine OPERATOR was started by system.

It appears it's not yet the turn of "COMMAND TERM HOLD OFF" which is
defined in the CP Directory.

So, is there a CONFIG statement or anything else to manage that?

Thank you,
Wolfgang Buettner

Software AG - Group Executive Board: Karl-Heinz Streibich 
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Dr. 
Hans Kraus, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev

Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany, - 
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management 
Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. 
Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the 
Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com/