Interestingly, when I brought up the first zLinux image, I needed to add the 
"LINK TCPMAINT 0592 0592 RR" statement to the PROFILE LNXDFLT and all zLinux 
images came up. However it caused the issue of LGR. Now I have the statement 
removed from the PROFILE, run directxa user command and reIPL all zVM LPARs and 
the LGR works.


-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Mark Pace
Sent: Friday, December 19, 2014 3:54 PM
To: [email protected]
Subject: Re: Problem to test relocating a Linux image to another z/VM - Device 
0592

Email sent from outside of PSEG. Use caution before using links/attachments.


Here is the exec/pipe that I run to detach all disks link R/O.

/* ********* ********************************************************
*\
   Name:
DETDISK
   Version:
1.0
   Author:   M.
Pace
   Function: Detach all disk linked
R/O
   Comments: Give Linux fewer disks to look at.

History:

\* ********* ********************************************************
*/
Trace
Off

Signal on
novalue
Parse upper source . . myname mytype mymode syn .


'PIPE (name
DETDISK.EXEC:13)',
   '|cp q v dasd
',
   '| locate w 5 %R/O%
',
   '| spec /DET / 1 w2 nw
',
   '| cp
',
   '|
console'



exit
0



ERREXIT:                              /* general errorexit routine
*/
 do i=2 to arg()                      /* give errormessages (if any)
*/
    say myname':' arg(i)              /* example: call errexit 99,'User
quit' */
 end

 exit
arg(1)


On Fri, Dec 19, 2014 at 3:43 PM, Alan Altmark <[email protected]>
wrote:

> On Friday, 12/19/2014 at 03:35 EST, "Chu, Raymond" 
> <[email protected]>
> wrote:
> > Mark,
> >
> > I am still a z/VM learner. Based on your comments, my PROFILE 
> > LNXDFLT
> for
> > TCPMAINT should be changed from
> >
> > LINK MAINT 0190 0190 RR
> > LINK MAINT 019D 019D RR
> > LINK MAINT 019E 019E RR
> > LINK LNXMAINT 0192 0191 RR
> > LINK TCPMAINT 0592 0592 RR
> >
> > To
> > LINK MAINT 0190 0190 R
> > LINK MAINT 019D 019D R
> > LINK MAINT 019E 019E R
> > LINK LNXMAINT 0192 0191 R
> > LINK TCPMAINT 0592 0592 R
> >
> > Shouldn't it?
>
> No, those disks should linked RR.  The problem is that MAINT and 
> TCPMAINT are IDENTITYs with SUBCONFIGs and those MDISKs are defined in 
> the SUBCONFIGs.  That means they are local disks.  If you want to 
> relocate the guest, you must first CP DETACH any linked minidisks that 
> are defined in a SUBCONFIG.
>
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant Lab Services System z 
> Delivery Practice IBM Systems & Technology Group 
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> [email protected]
> IBM Endicott
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions, send 
> email to [email protected] with the message: INFO LINUX-390 or 
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit 
> http://wiki.linuxvm.org/
>



--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit http://wiki.linuxvm.org/


-----------------------------------------
The information contained in this e-mail, including any attachment(s), is 
intended solely for use by the named addressee(s).  If you are not the intended 
recipient, or a person designated as responsible for delivering such messages 
to the intended recipient, you are not authorized to disclose, copy, distribute 
or retain this message, in whole or in part, without written authorization from 
PSEG.  This e-mail may contain proprietary, confidential or privileged 
information. If you have received this message in error, please notify the 
sender immediately. This notice is included in all e-mail messages leaving 
PSEG.  Thank you for your cooperation.

Reply via email to