George,

During "construction" of the virtual machine while it is being logged on, 
important CP messages and warnings may be displayed.  Unfortunately, by 
the time that the PROFILE EXEC is running, and the typical (for important 
service machines) "CP SPOOL CONSOLE * START" command is interpreted, some 
warnings and errors ay have already been reported.

A few releases ago, IBM provided the new CP directory statement to let us 
capture those messages in the SPOOLed console log (and for other uses, 
too!): COMMAND
It's a good idea for critical SVMs to include in their CP directory 
entries the statement (this is a short example, you can get more 
elaborate, e.g. setting a different "TO userid" destination):
COMMAND SPOOL CONSOLE START TO *

The COMMAND statement has specific requirements, examine it in the CP 
Planning and Administration manual.

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



"George Henke/NYLIC" <[email protected]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
11/01/2010 03:09 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: No IPL VSWITCH Connectivity







Aubry, 

I thought the same as you, but I AUTOLOG1 does have privclass (B): 

I am not quite sure where or how to check the LINUX logs. 

USER AUTOLOG1 AUTOLOG1 32M 32M ABCDEG                             
 AUTOLOG OP1 MAINT 
 ACCOUNT 9 SYSTEM                                                 
 MACH ESA                                                         
 IPL 190 
 CONSOLE 009 3215                                                 
 SPOOL 00C 2540 READER * 
 SPOOL 00D 2540 PUNCH  A 
 SPOOL 00E 1403 A                                                 
 LINK MAINTSYS 190 190 RR                                         
 MDISK 191 3390 2000 001 540RES  MR RAUTOLOG WAUTOLOG MAUTOLOG     


"Burch, Aubrey D Mr CIV DISA CDB12" <[email protected]> 
Sent by: The IBM z/VM Operating System <[email protected]> 
11/01/2010 04:04 PM 

Please respond to
The IBM z/VM Operating System <[email protected]>


To
[email protected] 
cc

Subject
Re: No IPL VSWITCH Connectivity








George,

>From the info you've given it sounds like the VSWITCH is being created
but the GRANT command within the AUTOLOG1 exec is failing. Check your
LINUX log to see if there is an error on the NIC while trying to
initialize. If so you might want to check to make sure that AUTOLOG1 has
the required privclass (B) to issue the SET VSWITCH command.

Regards,
Denny Burch

z/VM and z/LINUX Systems
DISA DECC Mechanicsburg
717 605-1181
(dsn) 430-1181


-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of George Henke/NYLIC
Sent: Monday, November 01, 2010 15:43
To: [email protected]
Subject: Re: No IPL VSWITCH Connectivity


My controllers. DTCVSW1,2 are  AUTOLOGed before the GRANTS, but there is
only a 10 sec sleep. 

'CP XAUTOLOG GCS' 
'CP XAUTOLOG DTCVSW1' 
'CP XAUTOLOG DTCVSW2' 
'CP SLEEP 10 SEC' 
'CP XAUTOLOG NETVIEW' 
'CP XAUTOLOG NETSPY' 
'CP XAUTOLOG OPERSYMP' 
'CP XAUTOLOG RSCSSERV' 
'CP XAUTOLOG VTAM' 

Also TCPIP IUCVs to VSWITCH. 

Does that mean TCPIP is acting as the CONTROLLER and must be up before
the GRANTS? 

USER TCPIP TCPIP 128M 256M ABG 
INCLUDE TCPCMSU 
OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON 
SHARE RELATIVE 3000 
IUCV ALLOW 
IUCV ANY PRIORITY 
IUCV *CCS PRIORITY MSGLIMIT 255 
IUCV *VSWITCH MSGLIMIT 65535 
* CHANGE SPECIAL FROM 9104 TO 9108 PER SAM  9/30/09 
SPECIAL 9108 QDIO 3 SYSTEM OSALAN 
LINK 5VMTCP40 491 491 RR 
LINK 5VMTCP40 492 492 RR 
LINK TCPMAINT 591 591 RR 
LINK TCPMAINT 592 592 RR 
LINK TCPMAINT 198 198 RR 
MDISK 191 3390 2258 005 540W02  MR RTCPIP   WTCPIP   MTCPIP 




Alan Altmark <[email protected]> 
Sent by: The IBM z/VM Operating System <[email protected]> 

11/01/2010 03:34 PM 
Please respond to
The IBM z/VM Operating System <[email protected]>

To
[email protected] 
cc
Subject
Re: No IPL VSWITCH Connectivity

 




On Monday, 11/01/2010 at 03:10 EDT, George Henke/NYLIC 
<[email protected]> wrote:
> After IPL we can destroy the VSWITCH: 
> 
> det vswitch lnxvsw1 
> 
> Then issue the same commands as in the IPL below and everything 
connects. 
> 
> Why? 
> 
> Are there some restrictions, considerations, for defining the VSWITCH
at 
IPL 
> time? 
> 
> SYSTEM CONFIG: 
> 
> define vswitch lnxvsw1 portname lnxvsw1 rdev 9004 

I suggest that you remove the PORTNAME LNXVSW1.  It isn't needed and it 
can create unnecessary confusion.

> AUTOLOG1: PROFILE EXEC: 
> 
> 'CP SET VSWITCH LNXVSW1 GRANT VLINUX1' 
> 'CP SET VSWITCH LNXVSW1 GRANT VLINUX2' 
> 'CP SET VSWITCH LNXVSW1 GRANT VLINUX3' 
> 'CP SET VSWITCH LNXVSW1 GRANT VLINUX4' 
> 'CP SET VSWITCH LNXVSW1 GRANT VLINUX5' 
> 'CP SLEEP 10 SEC' 

Why sleep 10 sec?  The SET VSWITCH commands take effect immediately.

> 'CP XAUTOLOG VLINUX1' 
> 'CP XAUTOLOG VLINUX2' 
> 'CP XAUTOLOG VLINUX3' 


A VSWITCH establishes connectivity to the outside world once the 
controllers (DTCVSW1/2) are up.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
[email protected]
IBM Endicott





The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Reply via email to