Maybe let's do a "Q VSWITCH LNXVSW1 DET" after IPL when it is NOT working. Then "SET VSWITCH LNXVSW1 CONNECT" let's see if it connects. Then QUERY it again.. Let's see what it looks like.
On Mon, Nov 1, 2010 at 1:17 PM, Mike Walter <[email protected]> wrote: > 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. >
