Re: Adding TDISK

[Kris Buelens]

You use STOP to avoid new stuff gets placed on the affected disk (TDISK,
Page, Spool).  When new stuff is welcome again, you use START.  To have CP
read the allocation map, an ATTACH to SYSTEM needs to be done, and that's
impossible when the disk is still attached to SYSTEM.

2009/9/16 Schuh, Richard 

>  The question is, can you start a disk that is al;ready started. Earlier
> discussions seemed to say that the allocation map is only read when the disk
> is attached to system. That would indicate that the START  command would be
> ineffective at increasing the amount of TDISK on an already started device.
>
>
> Regards,
> Richard Schuh
>
>
>
>
>  --
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Wandschneider, Scott
> *Sent:* Tuesday, September 15, 2009 2:53 PM
>
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: Adding TDISK
>
>  I thought a “START” disk command would do just that, reread the
> allocation – No?  Just start a drain volume?
>
>
>
> Thank you,
>
>
>
> Scott
>
>
>
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Scott Rohling
> *Sent:* Tuesday, September 15, 2009 4:50 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: Adding TDISK
>
>
>
> Unfortunately - I don't believe you can get zVM to reread the allocation
> table unless you detach/attach..  which you obviously can't do with your
> SYSRES..  so you'd have to re-IPL to get VM to see it...
>
> Scott
>
> On Tue, Sep 15, 2009 at 3:37 PM, Wandschneider, Scott <
> scott.wandschnei...@infocrossing.com> wrote:
>
> How I "start" TDISK?  The following is the procedure I followed.  Any
> help is appreciated.  Thanks.
>
> I did a CPFMTXA ALLOCATE on my 54BRES volume with the following command:
>
> CPFMTXA 123 54BRES ALLOCATE
> TDISK 1325.600
> END
>
> Result:
>  CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
>  TYPE START  ENDTOTAL
>   -  ----
>  PERM 0  0  1
>  DRCT 1  20 20
>  PERM 21 38 18
>  PARM 39 158120
>  PARM 159278120
>  PARM 279398120
>  PERM 3991324   926
>  TDSK 1325   1924   600
>  PERM 1925   3338   1414
>
> I have issued the following:
>
> sta dasd 891a TDISK
>
> Command complete
>
>  Ready; T=0.01/0.01 17:33:38
>
> q alloc
>
> DASD 891A 54BRES 3390 CKD-ECKD (UNITS IN CYLINDERS)
>
> TDISK TOTAL=000 INUSE=000 AVAIL=000
>
> PAGE  TOTAL=000 INUSE=000 AVAIL=000
>
> SPOOL TOTAL=000 INUSE=000 AVAIL=000
>
> DRCT  TOTAL=020 INUSE=001 AVAIL=019, ACTIVE
>
>
>
> Thank you,
> Scott R Wandschneider
>
> Confidentiality Note: This e-mail, including any attachment to it, may
> contain material that is confidential, proprietary, privileged and/or
> "Protected Health Information," within the meaning of the regulations under
> the Health Insurance Portability & Accountability Act as amended.  If it is
> not clear that you are the intended recipient, you are hereby notified that
> you have received this transmittal in error, and any review, dissemination,
> distribution or copying of this e-mail, including any attachment to it, is
> strictly prohibited. If you have received this e-mail in error, please
> immediately return it to the sender and delete it from your system. Thank
> you.
>
>
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: VM lockup due to storage typo

[Kris Buelens]

2009/9/15 Schuh, Richard 

> The same might be said for page space. Someone could access a dataspace
> enabled directory and take up page space. We could easily take up 48G of
> page space here by starting 24 machines that each access different d/s
> directories at 2G each.


Dataspace enabled directories are not paged out to paging space; the CP
paging operations for it are issued against the minidisks of the SFS
servers; neither are all dataspace pages brought in storage at the moment of
ACCESS.  The SFS dataspaces are called "mapped dataspaces".  A small
exception: the structures holding the FST blocks, they are not mapped to the
SFS server minidisks, they can page paged out to CP space (and obviously
CP's page management blocks occupy some storage too).
DB2/VM at the other hand, it can also use non-mapped dataspaces.

-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: VM lockup due to storage typo

[Alan Altmark]

On Tuesday, 09/15/2009 at 04:50 EDT, Marcy Cortes 
 wrote:
> So are you saying that what Lee and I both did to shoot our systems 
should 
> APAR'able?  Or should it be a requirement?  Or is it going to be a "your 
gun, 
> your foot" answer?

I was just answering the "Is it an integrity problem?" question:  No, it 
isn't an integrity problem.  The sysadmin did something that ultimately 
caused the system to lock up.  (That doesn't mean it was the sysadmin's 
fault, however.)

If you feel you have found a defect, open a PMR.  That's how you find out 
if something is really APARable.  :-)

Alan Altmark
z/VM Development
IBM Endicott

Re: Problem that is a blast from the past...

[Chip Davis]

I'm sorry to rise to the bait, but the nearly universal misunderstanding of the 
MAKEBUF command is one of my sore spots.



There is absolutely nothing about MAKEBUF that provides any sort of separation 
of the records in the program stack.  Successive reads from the stack will 
completely ignore any MAKEBUF point and happily continue to read records until 
the stack is empty, with no indication that a MAKEBUF point was passed.


To ensure that no more records are read from the program stack than were placed 
there after a MAKEBUF, it is necessary to do a Rexx Queued() or SENTRIES command 
at the MAKEBUF point to determine how many records are already on the stack, and 
then remove no more than were added after the MAKEBUF.  This essentially renders 
the MAKEBUF/DROPBUF superfluous.


The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the LIFO 
pointer.  This is quite handy because it allows one to place a group of records 
on the top of the stack in FIFO order. Without MAKEBUF, this operation would 
require reading all the records off the stack, stacking the new records FIFO, 
then restacking FIFO the original records.


The closest that MAKEBUF comes to a "separate what you place in the stack from 
what is already there" operation, is that if all of the records that were added 
to the program stack after a MAKEBUF command are not removed, the remaining 
records can be deleted with the appropriate DROPBUF.



If at some point, CMS is given the benefit of multiple program stacks (as in the 
TSO/REXX environment) you could truly "separate what you place in the stack from 
what is already there" by placing the new records in a new stack.  At that 
point, MAKEBUF and DROPBUF will become vestigial.  TSO/REXX's NEWSTACK/DELSTACK 
commands and the ability to create "a stack of stacks" is what everyone seems to 
think MAKEBUF/DROPBUF provides.


-Chip-

On 9/15/09 15:49 Kris Buelens said:
Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a 
server I'd say: you'd use it to separate what you place in the stack 
from what is there already, but as you code DROPBUF 0, there is surely 
nothing anymore to separate your stuff from.

Re: VM lockup due to storage typo

[Schuh, Richard]

> 
> One of the problems with booting Linux is that it determines 
> the size of the virtual machine by testing pages rather than 
> ask CP about it.

It only took TPF and its predecessors 35 years to get this right. :-)
Way back in VM/370 R3 I had a diag that could be used. We did talk 
the ACP Systems folks at TWA into using the diag instead of touching
Every page. We also had a mod in SVS to do the same (among other things).

 
> If I remember right, it tries the first page of every 
> architectured segment. 

It could be worse. Earlier systems (OS/360, MVS line of systems, ACP,   
VM, etc.) touched every page. The touching was usually done by setting
the storage key. 


Regards, 
Richard Schuh 

Re: VM lockup due to storage typo

[Rob van der Heij]

On Tue, Sep 15, 2009 at 11:18 PM, Robert J Brenneman  wrote:

> Admittedly - not 8TB in a 200G box, as Lee tried to do, and it was on
> z/VM 5.1, so it didn't have the system execution space stuff of later
> z/VM releases. It did teach the lesson that more page packs can only
> get you so far. At some point the system data structures needed to
> support the enormous guest just wont fit. This may be a reasonable
> calculation to make within CP as a sanity check.

If a factor of 2 does not make a difference, then try an order of
magnitude. :-)

One of the problems with booting Linux is that it determines the size
of the virtual machine by testing pages rather than ask CP about it.
If I remember right, it tries the first page of every architectured
segment. And to make it worse, it uses a test that also forces CP to
initialize the page frame. Which means that CP must also allocate a
PGMBK to hold the page tables to span that segment. So for each MB of
virtual machine storage, 3 pages must be allocated.
When I get the math right, the 8 TB virtual machine will very quickly
require 96 GB worth of page frames. That needs to come from
somewhere... A decent paging subsystem can fill up a single 3390-3 in
a minute or two.

And although we tell people that you need to add one 3390-3 page pack
for every GB of Linux server you define, there's still folks who think
we talk nonsense because with the first few Linux guests their z/VM
system did not page at all. But once you do start to page, page space
utilization growth is not subtle. It's more like shifting your cup of
coffee towards the edge of the table.

Rob

Re: Adding TDISK

[Schuh, Richard]

The question is, can you start a disk that is al;ready started. Earlier 
discussions seemed to say that the allocation map is only read when the disk is 
attached to system. That would indicate that the START  command would be 
ineffective at increasing the amount of TDISK on an already started device.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Wandschneider, Scott
Sent: Tuesday, September 15, 2009 2:53 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Adding TDISK

I thought a "START" disk command would do just that, reread the allocation - 
No?  Just start a drain volume?

Thank you,

Scott

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Scott Rohling
Sent: Tuesday, September 15, 2009 4:50 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Adding TDISK

Unfortunately - I don't believe you can get zVM to reread the allocation table 
unless you detach/attach..  which you obviously can't do with your SYSRES..  so 
you'd have to re-IPL to get VM to see it...

Scott
On Tue, Sep 15, 2009 at 3:37 PM, Wandschneider, Scott 
mailto:scott.wandschnei...@infocrossing.com>>
 wrote:
How I "start" TDISK?  The following is the procedure I followed.  Any
help is appreciated.  Thanks.

I did a CPFMTXA ALLOCATE on my 54BRES volume with the following command:

CPFMTXA 123 54BRES ALLOCATE
TDISK 1325.600
END

Result:
 CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
 TYPE START  ENDTOTAL
  -  ----
 PERM 0  0  1
 DRCT 1  20 20
 PERM 21 38 18
 PARM 39 158120
 PARM 159278120
 PARM 279398120
 PERM 3991324   926
 TDSK 1325   1924   600
 PERM 1925   3338   1414

I have issued the following:

sta dasd 891a TDISK

Command complete

 Ready; T=0.01/0.01 17:33:38

q alloc

DASD 891A 54BRES 3390 CKD-ECKD (UNITS IN CYLINDERS)

TDISK TOTAL=000 INUSE=000 AVAIL=000

PAGE  TOTAL=000 INUSE=000 AVAIL=000

SPOOL TOTAL=000 INUSE=000 AVAIL=000

DRCT  TOTAL=020 INUSE=001 AVAIL=019, ACTIVE



Thank you,
Scott R Wandschneider

Confidentiality Note: This e-mail, including any attachment to it, may contain 
material that is confidential, proprietary, privileged and/or "Protected Health 
Information," within the meaning of the regulations under the Health Insurance 
Portability & Accountability Act as amended.  If it is not clear that you are 
the intended recipient, you are hereby notified that you have received this 
transmittal in error, and any review, dissemination, distribution or copying of 
this e-mail, including any attachment to it, is strictly prohibited. If you 
have received this e-mail in error, please immediately return it to the sender 
and delete it from your system. Thank you.

Re: Adding TDISK

[Wandschneider, Scott]

I thought a “START” disk command would do just that, reread the allocation – 
No?  Just start a drain volume?

 

Thank you,

 

Scott

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Scott Rohling
Sent: Tuesday, September 15, 2009 4:50 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Adding TDISK

 

Unfortunately - I don't believe you can get zVM to reread the allocation table 
unless you detach/attach..  which you obviously can't do with your SYSRES..  so 
you'd have to re-IPL to get VM to see it...

Scott

On Tue, Sep 15, 2009 at 3:37 PM, Wandschneider, Scott 
 wrote:

How I "start" TDISK?  The following is the procedure I followed.  Any
help is appreciated.  Thanks.

I did a CPFMTXA ALLOCATE on my 54BRES volume with the following command:

CPFMTXA 123 54BRES ALLOCATE
TDISK 1325.600
END

Result:
 CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
 TYPE START  ENDTOTAL
  -  ----
 PERM 0  0  1
 DRCT 1  20 20
 PERM 21 38 18
 PARM 39 158120
 PARM 159278120
 PARM 279398120
 PERM 3991324   926
 TDSK 1325   1924   600
 PERM 1925   3338   1414

I have issued the following:

sta dasd 891a TDISK

Command complete

 Ready; T=0.01/0.01 17:33:38

q alloc

DASD 891A 54BRES 3390 CKD-ECKD (UNITS IN CYLINDERS)

TDISK TOTAL=000 INUSE=000 AVAIL=000

PAGE  TOTAL=000 INUSE=000 AVAIL=000

SPOOL TOTAL=000 INUSE=000 AVAIL=000

DRCT  TOTAL=020 INUSE=001 AVAIL=019, ACTIVE



Thank you,
Scott R Wandschneider

Confidentiality Note: This e-mail, including any attachment to it, may contain 
material that is confidential, proprietary, privileged and/or "Protected Health 
Information," within the meaning of the regulations under the Health Insurance 
Portability & Accountability Act as amended.  If it is not clear that you are 
the intended recipient, you are hereby notified that you have received this 
transmittal in error, and any review, dissemination, distribution or copying of 
this e-mail, including any attachment to it, is strictly prohibited. If you 
have received this e-mail in error, please immediately return it to the sender 
and delete it from your system. Thank you.

 


Confidentiality Note: This e-mail, including any attachment to it, may contain 
material that is confidential, proprietary, privileged and/or "Protected Health 
Information," within the meaning of the regulations under the Health Insurance 
Portability & Accountability Act as amended.  If it is not clear that you are 
the intended recipient, you are hereby notified that you have received this 
transmittal in error, and any review, dissemination, distribution or copying of 
this e-mail, including any attachment to it, is strictly prohibited. If you 
have received this e-mail in error, please immediately return it to the sender 
and delete it from your system. Thank you.

Re: Adding TDISK

[Scott Rohling]

Unfortunately - I don't believe you can get zVM to reread the allocation
table unless you detach/attach..  which you obviously can't do with your
SYSRES..  so you'd have to re-IPL to get VM to see it...

Scott

On Tue, Sep 15, 2009 at 3:37 PM, Wandschneider, Scott <
scott.wandschnei...@infocrossing.com> wrote:

> How I "start" TDISK?  The following is the procedure I followed.  Any
> help is appreciated.  Thanks.
>
> I did a CPFMTXA ALLOCATE on my 54BRES volume with the following command:
>
> CPFMTXA 123 54BRES ALLOCATE
> TDISK 1325.600
> END
>
> Result:
>  CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
>  TYPE START  ENDTOTAL
>   -  ----
>  PERM 0  0  1
>  DRCT 1  20 20
>  PERM 21 38 18
>  PARM 39 158120
>  PARM 159278120
>  PARM 279398120
>  PERM 3991324   926
>  TDSK 1325   1924   600
>  PERM 1925   3338   1414
>
> I have issued the following:
>
> sta dasd 891a TDISK
>
> Command complete
>
>  Ready; T=0.01/0.01 17:33:38
>
> q alloc
>
> DASD 891A 54BRES 3390 CKD-ECKD (UNITS IN CYLINDERS)
>
> TDISK TOTAL=000 INUSE=000 AVAIL=000
>
> PAGE  TOTAL=000 INUSE=000 AVAIL=000
>
> SPOOL TOTAL=000 INUSE=000 AVAIL=000
>
> DRCT  TOTAL=020 INUSE=001 AVAIL=019, ACTIVE
>
>
>
> Thank you,
> Scott R Wandschneider
>
> Confidentiality Note: This e-mail, including any attachment to it, may
> contain material that is confidential, proprietary, privileged and/or
> "Protected Health Information," within the meaning of the regulations under
> the Health Insurance Portability & Accountability Act as amended.  If it is
> not clear that you are the intended recipient, you are hereby notified that
> you have received this transmittal in error, and any review, dissemination,
> distribution or copying of this e-mail, including any attachment to it, is
> strictly prohibited. If you have received this e-mail in error, please
> immediately return it to the sender and delete it from your system. Thank
> you.
>

Adding TDISK

[Wandschneider, Scott]

How I "start" TDISK?  The following is the procedure I followed.  Any
help is appreciated.  Thanks.

I did a CPFMTXA ALLOCATE on my 54BRES volume with the following command:

CPFMTXA 123 54BRES ALLOCATE
TDISK 1325.600
END

Result:
  CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:  
  TYPE START  ENDTOTAL  
   -  ----  
  PERM 0  0  1  
  DRCT 1  20 20 
  PERM 21 38 18 
  PARM 39 158120
  PARM 159278120
  PARM 279398120
  PERM 3991324   926
  TDSK 1325   1924   600
  PERM 1925   3338   1414   

I have issued the following:

sta dasd 891a TDISK

Command complete

 Ready; T=0.01/0.01 17:33:38

q alloc

DASD 891A 54BRES 3390 CKD-ECKD (UNITS IN CYLINDERS)

 TDISK TOTAL=000 INUSE=000 AVAIL=000

 PAGE  TOTAL=000 INUSE=000 AVAIL=000

 SPOOL TOTAL=000 INUSE=000 AVAIL=000

 DRCT  TOTAL=020 INUSE=001 AVAIL=019, ACTIVE



Thank you,
Scott R Wandschneider

Confidentiality Note: This e-mail, including any attachment to it, may contain 
material that is confidential, proprietary, privileged and/or "Protected Health 
Information," within the meaning of the regulations under the Health Insurance 
Portability & Accountability Act as amended.  If it is not clear that you are 
the intended recipient, you are hereby notified that you have received this 
transmittal in error, and any review, dissemination, distribution or copying of 
this e-mail, including any attachment to it, is strictly prohibited. If you 
have received this e-mail in error, please immediately return it to the sender 
and delete it from your system. Thank you.

Re: VM lockup due to storage typo

[Schuh, Richard]

We all know that they are not M$ and we are glad they aren't.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Huegel, Thomas
> Sent: Tuesday, September 15, 2009 2:18 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> I would think that IBM would be scurring to fix what is 
> obviously a problem.
> After all they are not Microsoft... 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard
> Sent: Tuesday, September 15, 2009 4:13 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> Seems to me that he said it was either an integrity problem 
> or a defect.
> I would think that either would me meat for the APAR grinder.
> 
> Regards,
> Richard Schuh 
> 
>  
> 
> > -Original Message-
> > From: The IBM z/VM Operating System
> > [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes
> > Sent: Tuesday, September 15, 2009 1:50 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: VM lockup due to storage typo
> > 
> > So are you saying that what Lee and I both did to shoot our systems 
> > should APAR'able?  Or should it be a requirement?  Or is it 
> going to 
> > be a "your gun, your foot" answer?
> > 
> > 
> > Marcy
> >  
> > "This message may contain confidential and/or privileged 
> information. 
> > If you are not the addressee or authorized to receive this for the 
> > addressee, you must not use, copy, disclose, or take any 
> action based 
> > on this message or any information herein. If you have 
> received this 
> > message in error, please advise the sender immediately by 
> reply e-mail
> 
> > and delete this message. Thank you for your cooperation."
> > 
> > 
> > -Original Message-
> > From: The IBM z/VM Operating System
> > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> > Sent: Tuesday, September 15, 2009 1:45 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: [IBMVM] VM lockup due to storage typo
> > 
> > On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak 
> > 
> > wrote:
> > > I agree with that ("the guest cannot be allowed to harm 
> CP") but has
> > that
> > > actually been formally - or even informally - accepted by 
> the Powers
> > That
> > > Be?
> > 
> > Yes, it is in the Statement of System Integrity in the General 
> > Information Manual.
> > 
> > > I ask because I still remember, as though it were
> > yesterday, opening a
> > > security/integrity APAR against VM back in the mid-1980's
> > because any
> > > class G user could knock CP down by defining a shared and a
> > nonshared
> > > device on the same virtual control unit, and being told
> > that that was
> > NOT
> > > a security or integrity issue, and that no fix would be 
> forthcoming.
> > 
> > Under "today's" rules, that would be an Integrity problem.
> > 
> > o If a class G (only) user can repeatedly or with malice of 
> > forethought hang or abend CP, it WILL be classified as an integrity 
> > problem (denial of service).
> > 
> > o If a class G user happens to do something that triggers 
> an abend or 
> > hang due to a "system malfunction", it will NOT be classified as an 
> > integrity problem.
> > 
> > o If the system abends or hangs because it is overloaded (memory, 
> > CPU), it will NOT be classified as an integrity problem.
> > 
> > o Just because it isn't an integrity problem doesn't mean 
> it isn't a 
> > defect.
> > 
> > Alan Altmark
> > z/VM Development
> > IBM Endicott
> > 
> 

Re: VM lockup due to storage typo

[Robert J Brenneman]

I've tried wacky things like this before to see if I could run a 250G
guest on an lpar with ~140GB of memory and oodles of page space,
running z/VM 5.1

It came up, the guest initialized and Linux IPLed fine. It didn't have
a problem till I started running a memory thrasher in the Linux guest.
It sucked up all available memory and VM started paging, as you'd
guess. It kept making progress till it had used about 20% of the
paging space, but eventually VM itself started thrashing in its memory
management routines. Like a %SY of 500 or so  ( 5 processors running
memory management stuff?? ) I'd guess that VM itself ran out of space
below the 2G bar for page tables or something along that line. It
never abended though - it just thrashed itself for days.

Admittedly - not 8TB in a 200G box, as Lee tried to do, and it was on
z/VM 5.1, so it didn't have the system execution space stuff of later
z/VM releases. It did teach the lesson that more page packs can only
get you so far. At some point the system data structures needed to
support the enormous guest just wont fit. This may be a reasonable
calculation to make within CP as a sanity check.


-- 
Jay Brenneman

Re: VM lockup due to storage typo (OT)

[Schuh, Richard]

Marcy,

Did you get to attend any of those parties at the Malibu mansion?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes
> Sent: Tuesday, September 15, 2009 2:16 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
>  
> >Gee, I guess we're in good company!   ;-)
> You betcha! (I'm in MN today, I can say that).
> 
> At least mine was a test/dev system :)  If had done it to a 
> prod system, I'm sure someone here would have had IBM 
> answering questions ...  It's one of those things that fell 
> down low on the to pursue list - bigger fish frying.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 

Re: VM lockup due to storage typo

[Huegel, Thomas]

I would think that IBM would be scurring to fix what is obviously a
problem.
After all they are not Microsoft... 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 4:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo

Seems to me that he said it was either an integrity problem or a defect.
I would think that either would me meat for the APAR grinder.

Regards,
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes
> Sent: Tuesday, September 15, 2009 1:50 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> So are you saying that what Lee and I both did to shoot our systems 
> should APAR'able?  Or should it be a requirement?  Or is it going to 
> be a "your gun, your foot" answer?
> 
> 
> Marcy
>  
> "This message may contain confidential and/or privileged information. 
> If you are not the addressee or authorized to receive this for the 
> addressee, you must not use, copy, disclose, or take any action based 
> on this message or any information herein. If you have received this 
> message in error, please advise the sender immediately by reply e-mail

> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Tuesday, September 15, 2009 1:45 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: [IBMVM] VM lockup due to storage typo
> 
> On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak 
> 
> wrote:
> > I agree with that ("the guest cannot be allowed to harm CP") but has
> that
> > actually been formally - or even informally - accepted by the Powers
> That
> > Be?
> 
> Yes, it is in the Statement of System Integrity in the 
> General Information Manual.
> 
> > I ask because I still remember, as though it were 
> yesterday, opening a 
> > security/integrity APAR against VM back in the mid-1980's 
> because any 
> > class G user could knock CP down by defining a shared and a 
> nonshared 
> > device on the same virtual control unit, and being told 
> that that was
> NOT
> > a security or integrity issue, and that no fix would be forthcoming.
> 
> Under "today's" rules, that would be an Integrity problem.
> 
> o If a class G (only) user can repeatedly or with malice of 
> forethought hang or abend CP, it WILL be classified as an 
> integrity problem (denial of service).
> 
> o If a class G user happens to do something that triggers an 
> abend or hang due to a "system malfunction", it will NOT be 
> classified as an integrity problem.
> 
> o If the system abends or hangs because it is overloaded 
> (memory, CPU), it will NOT be classified as an integrity problem.
> 
> o Just because it isn't an integrity problem doesn't mean it 
> isn't a defect.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: VM lockup due to storage typo

[Marcy Cortes]

 
>Gee, I guess we're in good company!   ;-)
You betcha! (I'm in MN today, I can say that).

At least mine was a test/dev system :)  If had done it to a prod system, I'm 
sure someone here would have had IBM answering questions ...  It's one of those 
things that fell down low on the to pursue list - bigger fish frying.


Marcy 

"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."

Re: VM lockup due to storage typo

[Schuh, Richard]

Seems to me that he said it was either an integrity problem or a defect. I 
would think that either would me meat for the APAR grinder.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes
> Sent: Tuesday, September 15, 2009 1:50 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> So are you saying that what Lee and I both did to shoot our 
> systems should APAR'able?  Or should it be a requirement?  Or 
> is it going to be a "your gun, your foot" answer?
> 
> 
> Marcy 
>  
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Tuesday, September 15, 2009 1:45 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: [IBMVM] VM lockup due to storage typo
> 
> On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak 
> 
> wrote:
> > I agree with that ("the guest cannot be allowed to harm CP") but has
> that
> > actually been formally - or even informally - accepted by the Powers
> That
> > Be?
> 
> Yes, it is in the Statement of System Integrity in the 
> General Information Manual.
> 
> > I ask because I still remember, as though it were 
> yesterday, opening a 
> > security/integrity APAR against VM back in the mid-1980's 
> because any 
> > class G user could knock CP down by defining a shared and a 
> nonshared 
> > device on the same virtual control unit, and being told 
> that that was
> NOT
> > a security or integrity issue, and that no fix would be forthcoming.
> 
> Under "today's" rules, that would be an Integrity problem.
> 
> o If a class G (only) user can repeatedly or with malice of 
> forethought hang or abend CP, it WILL be classified as an 
> integrity problem (denial of service).
> 
> o If a class G user happens to do something that triggers an 
> abend or hang due to a "system malfunction", it will NOT be 
> classified as an integrity problem.
> 
> o If the system abends or hangs because it is overloaded 
> (memory, CPU), it will NOT be classified as an integrity problem.
> 
> o Just because it isn't an integrity problem doesn't mean it 
> isn't a defect.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: VM lockup due to storage typo

[John P. Baker]

First, since CP should know at all times how much space of each category
(PAGE, SPOL, etc.) is allocated, it should be able to immediately reject any
request (LOGON, DEFINE STOR, etc.) where the amount of storage requested
exceeds the amount of secondary storage configured.

Second, since CP "should" know at all times how much space of each category
(PAGE, SPOL, etc.) is in use, it should be able to immediately reject any
request (LOGON, DEFINE STOR, etc.) where the amount of storage requested
exceeds the amount of secondary storage available.

If this is not happening, I would argue that the situation should be
APAR'able as a system integrity bug.

Now, we can debate whether pages allocated, but not used, should be counted.
Should such pages require secondary storage backing availability, or should
secondary storage backing availability be required only when the page is
used?  Should this be a system configurable option?  Should this be a
virtual machine configurable option?

John P. Baker

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Lee Stewart
Sent: Tuesday, September 15, 2009 4:56 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo

Gee, I guess we're in good company!   ;-)

It does seem to me that CP should be smart enough to look at a 175GB 
real storage, 4GB Xstor, and xx number of page packs and say not in our 
wildest dreams can we run an 8TB virtual guest...

Or maybe at the point that the 8TB guest starts choking off all other 
activity and wildly filling page space

Lee

Re: Interesting articl

[Huegel, Thomas]

Yes, an interesting article.. Could the 5 include a) San Jose DASD
plant, b)Tucson tape storage plant ??   

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of P S
Sent: Tuesday, September 15, 2009 2:58 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Interesting articl

http://www.ciozone.com/index.php/Server-Technology-Zone/The-Mainframe-Th
e-Dinosaur-That-Wouldn-t-Die.html

Something that caught my eye:
"IBM...opened five major new plants."

Which five? Anyone know?

Re: VM lockup due to storage typo

[Lee Stewart]

Gee, I guess we're in good company!   ;-)

It does seem to me that CP should be smart enough to look at a 175GB 
real storage, 4GB Xstor, and xx number of page packs and say not in our 
wildest dreams can we run an 8TB virtual guest...


Or maybe at the point that the 8TB guest starts choking off all other 
activity and wildly filling page space


Lee

Marcy Cortes wrote:

See a thread on this list with subject "Sanity check?" from Oct 2007 for what 
happened when I did the same thing ;)

You probably filled page space.

I still think IBM should refuse to IPL a guest that will cause such harm.


Marcy 


"This message may contain confidential and/or privileged information. If you are not 
the addressee or authorized to receive this for the addressee, you must not use, copy, 
disclose, or take any action based on this message or any information herein. If you have 
received this message in error, please advise the sender immediately by reply e-mail and 
delete this message. Thank you for your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?


VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.


But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.


We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.


Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...


I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..


Any thoughts?
Lee


--

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com
Web:   www.siriuscom.com

Re: VM lockup due to storage typo

[Lee Stewart]

From the tn3270 sessions hanging to the phone call to me - 2-3 minutes. 
 From then till we decided we had to IPL - maybe 15-20 minutes.  But 30 
minutes (maybe 45-60 till all the apps were back up) on a major online 
system is a lot.   It was 35 minutes from the message capping the 
virtual storage at 8TB till the IPL time from Q CPLEVEL.  So no, not 
long considering the size.  And yes, I suspect it would PGT004 eventually.


And yes, if CP unceremoniously chopped my wrong size from 9.7TB to 8TB, 
why could it not do the same to either a user specified system limit or 
a "this is the biggest machine this CP can run in this configuration"...


Lee

Gentry, Stephen wrote:

What Lee doesn't mention is how long he waited before doing the IPL.
Had he waited to see what happens maybe VM would have finally come
around, so to speak. We all have different thresholds of pain. I think I
would have done what Lee did, long day, not really wanting to wait
around to see if VM recovers, just IPL.  Lee did you have access to the
HMC and thus the SAD screen to see what was going on? Sort of my last
line of defense if I can't get logged in.  Granted all it will tell you
is if you have CPU or I/O utilization, but at least you have something
to go to IBM with.
Maybe a SYSTEM CONFIG file option, like MAX_USER_SIZE, if it's set then
guest machine size is verified, if not available PAGE area and SPOOL
size is checked (calculated) and if the guest exceeds that size then the
quest doesn't start or a severe warning is issued.
Steve

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo

Maybe CP couldn't know that the guest would do something bad, but it
should know that it has opened itself to the possibility that the guest
could, in normal operation, cause the problem. 
One of Alan's first precepts of information security and integrity is

that the guest cannot be allowed to harm the CP. This clearly violates
that.

Regards, 
Richard Schuh 

 


-Original Message-
From: The IBM z/VM Operating System 
[mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch

Sent: Tuesday, September 15, 2009 9:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo

CP wouldn't know at IPL time, the guest would, not could, but 
would cause such harm.


Just because you say you can use xxx GB, doesn't mean you 
would actually use them.


When page fills, it over flows to spool.
When spool fills, CP abends on the next pageout.

Tom Duerbusch
THD Consulting

Marcy Cortes  9/15/2009 

11:02 AM >>>
See a thread on this list with subject "Sanity check?" from 
Oct 2007 for what happened when I did the same thing ;)


You probably filled page space.

I still think IBM should refuse to IPL a guest that will 
cause such harm.



Marcy 

"This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to 
receive this for the addressee, you must not use, copy, 
disclose, or take any action based on this message or any 
information herein. If you have received this message in 
error, please advise the sender immediately by reply e-mail 
and delete this message. Thank you for your cooperation."



-Original Message-
From: The IBM z/VM Operating System 
[mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart

Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of 
this without an IPL?


VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was 
updated and one by one the guests shutdown, logged off and 
back on.  So far, so good.


But... In changing the memory for many guests, and it being 
late at night after a long day, while meaning to set a 
guest's memory to 9728M, it got set to 9728G.  When that 
guest was cycled we see the message on the console that it's 
memory was limited to 8TB (HCPLGN093E), then the VM system 
appeared to freeze.


We couldn't get in via TCP/IP, or the HMC Operating System 
Messages screen, or the HMC Integrated 3270.


Finally had to IPL.   Even that was wierd as I'd have 
expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...


I suspect CP was scrambling paging everything in the world 
out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised 
I couldn't 
even get into the HMC consoles (to kill just that one guest 
as opposed to all of them)..


Any thoughts?
Lee
--

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com 
Web:   www.siriuscom.com







--

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew.

Re: VM lockup due to storage typo

[Marcy Cortes]

So are you saying that what Lee and I both did to shoot our systems should 
APAR'able?  Or should it be a requirement?  Or is it going to be a "your gun, 
your foot" answer?


Marcy 
 
"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Alan Altmark
Sent: Tuesday, September 15, 2009 1:45 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] VM lockup due to storage typo

On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak  
wrote:
> I agree with that ("the guest cannot be allowed to harm CP") but has 
that
> actually been formally - or even informally - accepted by the Powers 
That
> Be?

Yes, it is in the Statement of System Integrity in the General Information 
Manual.

> I ask because I still remember, as though it were yesterday, opening a
> security/integrity APAR against VM back in the mid-1980's because any
> class G user could knock CP down by defining a shared and a nonshared
> device on the same virtual control unit, and being told that that was 
NOT
> a security or integrity issue, and that no fix would be forthcoming.

Under "today's" rules, that would be an Integrity problem.

o If a class G (only) user can repeatedly or with malice of forethought 
hang or abend CP, it WILL be classified as an integrity problem (denial of 
service).

o If a class G user happens to do something that triggers an abend or hang 
due to a "system malfunction", it will NOT be classified as an integrity 
problem.

o If the system abends or hangs because it is overloaded (memory, CPU), it 
will NOT be classified as an integrity problem.

o Just because it isn't an integrity problem doesn't mean it isn't a 
defect.

Alan Altmark
z/VM Development
IBM Endicott

Re: VM lockup due to storage typo

[Alan Altmark]

On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak  
wrote:
> I agree with that ("the guest cannot be allowed to harm CP") but has 
that
> actually been formally - or even informally - accepted by the Powers 
That
> Be?

Yes, it is in the Statement of System Integrity in the General Information 
Manual.

> I ask because I still remember, as though it were yesterday, opening a
> security/integrity APAR against VM back in the mid-1980's because any
> class G user could knock CP down by defining a shared and a nonshared
> device on the same virtual control unit, and being told that that was 
NOT
> a security or integrity issue, and that no fix would be forthcoming.

Under "today's" rules, that would be an Integrity problem.

o If a class G (only) user can repeatedly or with malice of forethought 
hang or abend CP, it WILL be classified as an integrity problem (denial of 
service).

o If a class G user happens to do something that triggers an abend or hang 
due to a "system malfunction", it will NOT be classified as an integrity 
problem.

o If the system abends or hangs because it is overloaded (memory, CPU), it 
will NOT be classified as an integrity problem.

o Just because it isn't an integrity problem doesn't mean it isn't a 
defect.

Alan Altmark
z/VM Development
IBM Endicott

Re: VM lockup due to storage typo

[Schuh, Richard]

The same might be said for page space. Someone could access a dataspace enabled 
directory and take up page space. We could easily take up 48G of page space 
here by starting 24 machines that each access different d/s directories at 2G 
each. And others could define storage from default to max. Then there are those 
pesky V-disk users - they could increase the load on page space. 

But I do agree that spool space should not enter into the equation when 
determining if there is enough page space.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen
> Sent: Tuesday, September 15, 2009 12:31 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> You can't include SPOOL space in the check for "is there 
> enough page spac= e to allow this guest" decision.  SPOOL 
> space that was available earlier ma= y not be there later 
> when you "need" it as overflow PAGE space.  Any guest =
> 
> can fill up your SPOOL space at any time.
> 
> Brian Nielsen
> 
> 
> 
> On Tue, 15 Sep 2009 13:13:40 -0400, Gentry, Stephen 
>  wrote:
> 
> >What Lee doesn't mention is how long he waited before doing the IPL.
> >Had he waited to see what happens maybe VM would have finally come 
> >around, so to speak. We all have different thresholds of 
> pain. I think 
> >I=
> 
> >would have done what Lee did, long day, not really wanting to wait 
> >around to see if VM recovers, just IPL.  Lee did you have 
> access to the 
> >HMC and thus the SAD screen to see what was going on? Sort 
> of my last 
> >line of defense if I can't get logged in.  Granted all it 
> will tell you 
> >is if you have CPU or I/O utilization, but at least you have 
> something 
> >to go to IBM with.
> >Maybe a SYSTEM CONFIG file option, like MAX_USER_SIZE, if 
> it's set then 
> >guest machine size is verified, if not available PAGE area and SPOOL 
> >size is checked (calculated) and if the guest exceeds that size then 
> >the=
> 
> >quest doesn't start or a severe warning is issued.
> >Steve
> >
> >-Original Message-
> >From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On 
> >Behalf Of Schuh, Richard
> >Sent: Tuesday, September 15, 2009 12:59 PM
> >To: IBMVM@LISTSERV.UARK.EDU
> >Subject: Re: VM lockup due to storage typo
> >
> >Maybe CP couldn't know that the guest would do something bad, but it 
> >should know that it has opened itself to the possibility 
> that the guest 
> >could, in normal operation, cause the problem.
> >One of Alan's first precepts of information security and 
> integrity is 
> >that the guest cannot be allowed to harm the CP. This 
> clearly violates 
> >that.
> >
> >Regards,
> >Richard Schuh
> >
> > 
> >
> >> -Original Message-
> >> From: The IBM z/VM Operating System
> >> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
> >> Sent: Tuesday, September 15, 2009 9:19 AM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: Re: VM lockup due to storage typo
> >> 
> >> CP wouldn't know at IPL time, the guest would, not could, 
> but would 
> >> cause such harm.
> >> 
> >> Just because you say you can use xxx GB, doesn't mean you would 
> >> actually use them.
> >> 
> >> When page fills, it over flows to spool.
> >> When spool fills, CP abends on the next pageout.
> >> 
> >> Tom Duerbusch
> >> THD Consulting
> >> 
> >> >>> Marcy Cortes  9/15/2009
> >> 11:02 AM >>>
> >> See a thread on this list with subject "Sanity check?" 
> from Oct 2007 
> >> for what happened when I did the same thing ;)
> >> 
> >> You probably filled page space.
> >> 
> >> I still think IBM should refuse to IPL a guest that will 
> cause such 
> >> harm.
> >> 
> >> 
> >> Marcy
> >> 
> >> "This message may contain confidential and/or privileged 
> information. 
> >> If you are not the addressee or authorized to receive this for the 
> >> addressee, you must not use, copy, disclose, or take any 
> action based 
> >> on this message or any information herein. If you have 
> received this 
> >> message in error, please advise the sender immediately by reply 
> >> e-mail and delete this message. Thank you for your cooperation."
> >> 
> >> 
> >> -Original Message-
> >> From: The IBM z/VM Operating System 
> >> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> >> Sent: Tuesday, September 15, 2009 8:39 AM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: [IBMVM] VM lockup due to storage typo
> >> 
> >> Does anyone have an idea of how we might have gotten out of 
> >> this without an IPL?
> >> 
> >> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> >> Several guests needed more memory added so the directory was 
> >> updated and one by one the guests shutdown, logged off and 
> >> back on.  So far, so good.
> >> 
> >> But... In changing the memory for many guests, and it being 
> >> late at night after a long day, while meaning to set a 
> >> guest's memory to 9728M, it got set

Re: Printers to 2nd level VM...

[Ward, Mike S]

Wouldn't virtual printers defined in the directory work just as well?

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Tom Duerbusch
Sent: Tuesday, September 15, 2009 10:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Printers to 2nd level VM...

Yep, that is what he said...
And as I don't trust computers, you know I never trust people .

If it isn't that, then the printers need to be attached to the second
level system during the IPL of the second level system.  

In my experience, printers don't sense too well.
If you IPL with the printers attached, and it still doesn't sense
properly, perhaps there is a SET RDEVICE in the autolog process, or in
the Operators profile.

But, if this volume was truely cloned, all that should be there.
So that brings me back to IPL with the devices attached and see what you
get.  Or at least attach one of them for testing.

The other thing that may be different with a second level system, is if
you are doing the same saipl that you are in hardware.  Sometimes you
forget that the hardware IPL, may be accessing a different disk than
CF1.

Tom Duerbusch
THD Consulting

>>> Robert Payne  9/15/2009 10:28 AM >>>
but I thought he said that he cloned the volumes, so the CONFIG should
already be in place ...


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on 
Behalf Of Tom Duerbusch
Sent: Tuesday, September 15, 2009 10:26 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: Printers to 2nd level VM...


You have to define the printers to your second level VM system.
... big snip
==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

Interesting articl

[P S]

http://www.ciozone.com/index.php/Server-Technology-Zone/The-Mainframe-The-Dinosaur-That-Wouldn-t-Die.html

Something that caught my eye:
"IBM...opened five major new plants."

Which five? Anyone know?

Re: VM lockup due to storage typo

[Tom Duerbusch]

Good point.

When I have hit this, I got a PAGxxx type error and CP automatically reipl'ed.

Like I said, when the offending user starts allocating pages, all the other 
machines will abend on a paging error when their recently used pages are tried 
to be paged out.  Eventually, some of CP pagable pages will be the least 
recently used pages and BAM!  PAGxxx CP abend.  Automatic restart in progress...

Tom Duerbusch
THD Consulting

>>> "Gentry, Stephen"  9/15/2009 12:13 PM >>>
What Lee doesn't mention is how long he waited before doing the IPL.
Had he waited to see what happens maybe VM would have finally come
around, so to speak. We all have different thresholds of pain. I think I
would have done what Lee did, long day, not really wanting to wait
around to see if VM recovers, just IPL.  Lee did you have access to the
HMC and thus the SAD screen to see what was going on? Sort of my last
line of defense if I can't get logged in.  Granted all it will tell you
is if you have CPU or I/O utilization, but at least you have something
to go to IBM with.
Maybe a SYSTEM CONFIG file option, like MAX_USER_SIZE, if it's set then
guest machine size is verified, if not available PAGE area and SPOOL
size is checked (calculated) and if the guest exceeds that size then the
quest doesn't start or a severe warning is issued.
Steve

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: VM lockup due to storage typo

Maybe CP couldn't know that the guest would do something bad, but it
should know that it has opened itself to the possibility that the guest
could, in normal operation, cause the problem. 
One of Alan's first precepts of information security and integrity is
that the guest cannot be allowed to harm the CP. This clearly violates
that.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
> Sent: Tuesday, September 15, 2009 9:19 AM
> To: IBMVM@LISTSERV.UARK.EDU 
> Subject: Re: VM lockup due to storage typo
> 
> CP wouldn't know at IPL time, the guest would, not could, but 
> would cause such harm.
> 
> Just because you say you can use xxx GB, doesn't mean you 
> would actually use them.
> 
> When page fills, it over flows to spool.
> When spool fills, CP abends on the next pageout.
> 
> Tom Duerbusch
> THD Consulting
> 
> >>> Marcy Cortes  9/15/2009 
> 11:02 AM >>>
> See a thread on this list with subject "Sanity check?" from 
> Oct 2007 for what happened when I did the same thing ;)
> 
> You probably filled page space.
> 
> I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> Sent: Tuesday, September 15, 2009 8:39 AM
> To: IBMVM@LISTSERV.UARK.EDU 
> Subject: [IBMVM] VM lockup due to storage typo
> 
> Does anyone have an idea of how we might have gotten out of 
> this without an IPL?
> 
> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> Several guests needed more memory added so the directory was 
> updated and one by one the guests shutdown, logged off and 
> back on.  So far, so good.
> 
> But... In changing the memory for many guests, and it being 
> late at night after a long day, while meaning to set a 
> guest's memory to 9728M, it got set to 9728G.  When that 
> guest was cycled we see the message on the console that it's 
> memory was limited to 8TB (HCPLGN093E), then the VM system 
> appeared to freeze.
> 
> We couldn't get in via TCP/IP, or the HMC Operating System 
> Messages screen, or the HMC Integrated 3270.
> 
> Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
> and all came back up ok...
> 
> I suspect CP was scrambling paging everything in the world 
> out as Linux 
> tried to initialize that 8TB of memory...   But I'm surprised 
> I couldn't 
> even get into the HMC consoles (to kill just that one guest 
> as opposed to all of them)..
> 
> Any thoughts?
> Lee
> -- 
> 
> Lee Stewart, Senior SE
> Sirius Computer Solutions
> Phone: (303) 996-7122
> Email: lee.stew...@siriuscom.com 
> Web:   www.siriuscom.com 
> 

Re: VM lockup due to storage typo

[Brian Nielsen]

You can't include SPOOL space in the check for "is there enough page spac
e 
to allow this guest" decision.  SPOOL space that was available earlier ma
y 
not be there later when you "need" it as overflow PAGE space.  Any guest 

can fill up your SPOOL space at any time.

Brian Nielsen



On Tue, 15 Sep 2009 13:13:40 -0400, Gentry, Stephen 
 wrote:

>What Lee doesn't mention is how long he waited before doing the IPL.
>Had he waited to see what happens maybe VM would have finally come
>around, so to speak. We all have different thresholds of pain. I think I

>would have done what Lee did, long day, not really wanting to wait
>around to see if VM recovers, just IPL.  Lee did you have access to the
>HMC and thus the SAD screen to see what was going on? Sort of my last
>line of defense if I can't get logged in.  Granted all it will tell you
>is if you have CPU or I/O utilization, but at least you have something
>to go to IBM with.
>Maybe a SYSTEM CONFIG file option, like MAX_USER_SIZE, if it's set then
>guest machine size is verified, if not available PAGE area and SPOOL
>size is checked (calculated) and if the guest exceeds that size then the

>quest doesn't start or a severe warning is issued.
>Steve
>
>-Original Message-
>From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
>Behalf Of Schuh, Richard
>Sent: Tuesday, September 15, 2009 12:59 PM
>To: IBMVM@LISTSERV.UARK.EDU
>Subject: Re: VM lockup due to storage typo
>
>Maybe CP couldn't know that the guest would do something bad, but it
>should know that it has opened itself to the possibility that the guest
>could, in normal operation, cause the problem. 
>One of Alan's first precepts of information security and integrity is
>that the guest cannot be allowed to harm the CP. This clearly violates
>that.
>
>Regards, 
>Richard Schuh 
>
> 
>
>> -Original Message-
>> From: The IBM z/VM Operating System 
>> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
>> Sent: Tuesday, September 15, 2009 9:19 AM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: Re: VM lockup due to storage typo
>> 
>> CP wouldn't know at IPL time, the guest would, not could, but 
>> would cause such harm.
>> 
>> Just because you say you can use xxx GB, doesn't mean you 
>> would actually use them.
>> 
>> When page fills, it over flows to spool.
>> When spool fills, CP abends on the next pageout.
>> 
>> Tom Duerbusch
>> THD Consulting
>> 
>> >>> Marcy Cortes  9/15/2009 
>> 11:02 AM >>>
>> See a thread on this list with subject "Sanity check?" from 
>> Oct 2007 for what happened when I did the same thing ;)
>> 
>> You probably filled page space.
>> 
>> I still think IBM should refuse to IPL a guest that will 
>> cause such harm.
>> 
>> 
>> Marcy 
>> 
>> "This message may contain confidential and/or privileged 
>> information. If you are not the addressee or authorized to 
>> receive this for the addressee, you must not use, copy, 
>> disclose, or take any action based on this message or any 
>> information herein. If you have received this message in 
>> error, please advise the sender immediately by reply e-mail 
>> and delete this message. Thank you for your cooperation."
>> 
>> 
>> -Original Message-
>> From: The IBM z/VM Operating System 
>> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
>> Sent: Tuesday, September 15, 2009 8:39 AM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: [IBMVM] VM lockup due to storage typo
>> 
>> Does anyone have an idea of how we might have gotten out of 
>> this without an IPL?
>> 
>> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
>> Several guests needed more memory added so the directory was 
>> updated and one by one the guests shutdown, logged off and 
>> back on.  So far, so good.
>> 
>> But... In changing the memory for many guests, and it being 
>> late at night after a long day, while meaning to set a 
>> guest's memory to 9728M, it got set to 9728G.  When that 
>> guest was cycled we see the message on the console that it's 
>> memory was limited to 8TB (HCPLGN093E), then the VM system 
>> appeared to freeze.
>> 
>> We couldn't get in via TCP/IP, or the HMC Operating System 
>> Messages screen, or the HMC Integrated 3270.
>> 
>> Finally had to IPL.   Even that was wierd as I'd have 
>> expected the Load 
>> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 

>> and all came back up ok...
>> 
>> I suspect CP was scrambling paging everything in the world 
>> out as Linux 
>> tried to initialize that 8TB of memory...   But I'm surprised 
>> I couldn't 
>> even get into the HMC consoles (to kill just that one guest 
>> as opposed to all of them)..
>> 
>> Any thoughts?
>> Lee
>> -- 
>> 
>> Lee Stewart, Senior SE
>> Sirius Computer Solutions
>> Phone: (303) 996-7122
>> Email: lee.stew...@siriuscom.com 
>> Web:   www.siriuscom.com
>> 

Re: VM lockup due to storage typo

[Steve Marak]

I agree with that ("the guest cannot be allowed to harm CP") but has that 
actually been formally - or even informally - accepted by the Powers That 
Be?

I ask because I still remember, as though it were yesterday, opening a 
security/integrity APAR against VM back in the mid-1980's because any 
class G user could knock CP down by defining a shared and a nonshared 
device on the same virtual control unit, and being told that that was NOT 
a security or integrity issue, and that no fix would be forthcoming. 

But at least I'm not bitter about it. 

Steve

On Tue, 15 Sep 2009, Schuh, Richard wrote:

> One of Alan's first precepts of information security and integrity is 
> that the guest cannot be allowed to harm the CP. This clearly violates 
> that.
> 
> Regards, 
> Richard Schuh 

-- Steve Marak
-- sama...@gizmoworks.com

Re: VM lockup due to storage typo

[Gentry, Stephen]

What Lee doesn't mention is how long he waited before doing the IPL.
Had he waited to see what happens maybe VM would have finally come
around, so to speak. We all have different thresholds of pain. I think I
would have done what Lee did, long day, not really wanting to wait
around to see if VM recovers, just IPL.  Lee did you have access to the
HMC and thus the SAD screen to see what was going on? Sort of my last
line of defense if I can't get logged in.  Granted all it will tell you
is if you have CPU or I/O utilization, but at least you have something
to go to IBM with.
Maybe a SYSTEM CONFIG file option, like MAX_USER_SIZE, if it's set then
guest machine size is verified, if not available PAGE area and SPOOL
size is checked (calculated) and if the guest exceeds that size then the
quest doesn't start or a severe warning is issued.
Steve

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Schuh, Richard
Sent: Tuesday, September 15, 2009 12:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM lockup due to storage typo

Maybe CP couldn't know that the guest would do something bad, but it
should know that it has opened itself to the possibility that the guest
could, in normal operation, cause the problem. 
One of Alan's first precepts of information security and integrity is
that the guest cannot be allowed to harm the CP. This clearly violates
that.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
> Sent: Tuesday, September 15, 2009 9:19 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> CP wouldn't know at IPL time, the guest would, not could, but 
> would cause such harm.
> 
> Just because you say you can use xxx GB, doesn't mean you 
> would actually use them.
> 
> When page fills, it over flows to spool.
> When spool fills, CP abends on the next pageout.
> 
> Tom Duerbusch
> THD Consulting
> 
> >>> Marcy Cortes  9/15/2009 
> 11:02 AM >>>
> See a thread on this list with subject "Sanity check?" from 
> Oct 2007 for what happened when I did the same thing ;)
> 
> You probably filled page space.
> 
> I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> Sent: Tuesday, September 15, 2009 8:39 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: [IBMVM] VM lockup due to storage typo
> 
> Does anyone have an idea of how we might have gotten out of 
> this without an IPL?
> 
> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> Several guests needed more memory added so the directory was 
> updated and one by one the guests shutdown, logged off and 
> back on.  So far, so good.
> 
> But... In changing the memory for many guests, and it being 
> late at night after a long day, while meaning to set a 
> guest's memory to 9728M, it got set to 9728G.  When that 
> guest was cycled we see the message on the console that it's 
> memory was limited to 8TB (HCPLGN093E), then the VM system 
> appeared to freeze.
> 
> We couldn't get in via TCP/IP, or the HMC Operating System 
> Messages screen, or the HMC Integrated 3270.
> 
> Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
> and all came back up ok...
> 
> I suspect CP was scrambling paging everything in the world 
> out as Linux 
> tried to initialize that 8TB of memory...   But I'm surprised 
> I couldn't 
> even get into the HMC consoles (to kill just that one guest 
> as opposed to all of them)..
> 
> Any thoughts?
> Lee
> -- 
> 
> Lee Stewart, Senior SE
> Sirius Computer Solutions
> Phone: (303) 996-7122
> Email: lee.stew...@siriuscom.com 
> Web:   www.siriuscom.com
> 

Re: How much memory?

[Michael Coffin]

He can share the storage if the Linux guest is a virtual machine, but he
won't be able to use the IFL AND his general purpose CP(s) in the same
LPAR.  He'd need a z10 with an LPAR configured with the new ZVM support
to mix/match different processors in the same LPAR.  This was actually
our justification for getting a z10, the ability to mix IFL's and CP's
in the same LPAR.  :)
 
PS:  How much storage you need for your Linux LPAR depends on what you
want to use Linux for, but I've run production Linux systems (SuSE,
RedHat and Debian) in just a few hundred MB and they ran Apache web
servers, LVM, DB2/Connect, mail servers and a ton of other stuff with no
problems.  :)
 
-Mike

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Scott Rohling
Sent: Monday, September 14, 2009 10:01 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How much memory?


It will depend on what your POC encompasses.. how many Linux guests?
What software/middleware?.

You might want to consider a 2nd level guest rather than building a
separate LPAR -- that way you can manage things under a single zVM and
dynamically change things (give your 2nd level zVM more storage, for
example) much more easily...

Scott


On Mon, Sep 14, 2009 at 7:52 AM, Vince Getgood
 wrote:


Hi all,
I'm not a VM expert, so forgive me if this seems a newbie quetion.

I have a z800 running z/VM, which has two production z/OS guests, and
the
usual collection of CMS guests (TCPIP / OPERATOR etc).

We discovered recently that the z800 has an IFL (long story - don't
ask!)
and would like to steal some of the 8GB currently allocated to VM, to
run
up a VM / Linux LPAR for a POC.

The two z/OS guests are defined at 256MB & 512MB (Bill Gates, are you
watching??), and don't page.

In your most esteemed opinion, what could I steal from the VM LPAR
without
hurting it's and the guests performance / making it page?

Personally, I think 2GB would be enough.

Comments and opinions welcome.

Re: VM lockup due to storage typo

[Schuh, Richard]

CMS, being a 32-bit system, will probably never use 3TB of memory. Perhaps 
z/CMS, when it becomes a reality, might but the current CMS is another story. 

Regards, 
Richard Schuh 

 

>  CMS u= ses all of its storage over 
> time. Both will use all of their storage eventual= ly. 
> 

SET LINUX390 DIGEST

[Eileen Digan]

Thanks  later, 
Eileen

Eileen M. Digan 
z/VM and Linux Systems Management Development
(845) 435 - 5204 / tieline 8 - 295  - 5204 
email: di...@us.ibm.com

Only One Priority Can Be Number One.

Re: VM lockup due to storage typo

[Tom Duerbusch]

CMS will free its storage after the command is complete.

However, do a peek on a very large reader element, such as a OS dump, and CMS 
just might use up all of its storage, just like any other guest might.

It isn't a matter of time, it is a matter of usage.

Tom Duerbusch
THD Consulting

>>> Thomas Kern  9/15/2009 12:48 PM >>>
The difference between CMS and Linux in this case is just a matter of time
before problems occur. Linux wants to use all of its storage early, CMS uses
all of its storage over time. Both will use all of their storage eventually. 

CP is built to overcommit storage. It just lets you REALLY overcommit
storage. But it would be nice if there was some sort of sanity check in
there somewhere. 

/Tom Kern

On Tue, 15 Sep 2009 13:12:38 -0400, Bruce Hayden  wrote:

>The problem isn't that you did an IPL, it is that you IPLed Linux.  An
>IPL of CMS in an 8 TB machine doesn't have any delay or cause a
>problem:
>
>def stor 8t
>STORAGE = 8T
>Storage cleared - system reset.
>i cms
>z/VM V5.4.02009-07-13 11:58
>
>Ready; T=0.01/0.01 13:06:21
>q v stor
>STORAGE = 8T
>Ready; T=0.01/0.01 13:06:26
>q stor
>STORAGE = 4G CONFIGURED = 4G INC = 128M STANDBY = 8G RESERVED = 0
>Ready; T=0.01/0.01 13:06:57
>
>An IPL of ZCMS blows up, though.  Maybe they didn't test it with that
>large storage.
>
>On Tue, Sep 15, 2009 at 12:02 PM, Marcy Cortes
> wrote:
>> See a thread on this list with subject "Sanity check?" from Oct 2007 for
what happened when I did the same thing ;)
>>
>> You probably filled page space.
>>
>> I still think IBM should refuse to IPL a guest that will cause such harm.
>>
>>
>> Marcy
>>
>
>
>--
>Bruce Hayden
>Linux on System z Advanced Technical Support
>IBM, Endicott, NY

Re: VM lockup due to storage typo

[Thomas Kern]

The difference between CMS and Linux in this case is just a matter of tim
e
before problems occur. Linux wants to use all of its storage early, CMS u
ses
all of its storage over time. Both will use all of their storage eventual
ly. 

CP is built to overcommit storage. It just lets you REALLY overcommit
storage. But it would be nice if there was some sort of sanity check in
there somewhere. 

/Tom Kern

On Tue, 15 Sep 2009 13:12:38 -0400, Bruce Hayden  wro
te:

>The problem isn't that you did an IPL, it is that you IPLed Linux.  An
>IPL of CMS in an 8 TB machine doesn't have any delay or cause a
>problem:
>
>def stor 8t
>STORAGE = 8T
>Storage cleared - system reset.
>i cms
>z/VM V5.4.02009-07-13 11:58
>
>Ready; T=0.01/0.01 13:06:21
>q v stor
>STORAGE = 8T
>Ready; T=0.01/0.01 13:06:26
>q stor
>STORAGE = 4G CONFIGURED = 4G INC = 128M STANDBY = 8G RESERVED =
 0
>Ready; T=0.01/0.01 13:06:57
>
>An IPL of ZCMS blows up, though.  Maybe they didn't test it with that
>large storage.
>
>On Tue, Sep 15, 2009 at 12:02 PM, Marcy Cortes
> wrote:
>> See a thread on this list with subject "Sanity check?" from Oct 2007 f
or
what happened when I did the same thing ;)
>>
>> You probably filled page space.
>>
>> I still think IBM should refuse to IPL a guest that will cause such ha
rm.
>>
>>
>> Marcy
>>
>
>
>--
>Bruce Hayden
>Linux on System z Advanced Technical Support
>IBM, Endicott, NY

Re: VM lockup due to storage typo

[Bruce Hayden]

The problem isn't that you did an IPL, it is that you IPLed Linux.  An
IPL of CMS in an 8 TB machine doesn't have any delay or cause a
problem:

def stor 8t
STORAGE = 8T
Storage cleared - system reset.
i cms
z/VM V5.4.02009-07-13 11:58

Ready; T=0.01/0.01 13:06:21
q v stor
STORAGE = 8T
Ready; T=0.01/0.01 13:06:26
q stor
STORAGE = 4G CONFIGURED = 4G INC = 128M STANDBY = 8G RESERVED = 0
Ready; T=0.01/0.01 13:06:57

An IPL of ZCMS blows up, though.  Maybe they didn't test it with that
large storage.

On Tue, Sep 15, 2009 at 12:02 PM, Marcy Cortes
 wrote:
> See a thread on this list with subject "Sanity check?" from Oct 2007 for what 
> happened when I did the same thing ;)
>
> You probably filled page space.
>
> I still think IBM should refuse to IPL a guest that will cause such harm.
>
>
> Marcy
>


-- 
Bruce Hayden
Linux on System z Advanced Technical Support
IBM, Endicott, NY

Re: VM lockup due to storage typo

[Tom Duerbusch]

Thinking about this a little futher

How could 1 error cause this?

In the user direct, the user statement has:

USER LINUX27  xx  32M 600M G 

There are two memory related parms.  The one your guest machine is built with, 
in this case 32 MB.
The other is the maximum memory size for your guest, in this case 600 MB.

With either the initial size, or the dynamically defined size via a DEF STOR 
command, you can't exceed the maximum size.

So to define 8 TB of storage, you have to change the max size to be something 
very large.
And then define the machine to use that size.

So it seems to me that there are two mistakes.  

You told CP you might want a very large size, and when you finally asked for 
it, it obeyed.
That isn't a CP error.

The same problem occurs when you tell CP that you are ok with TB sized vdisks.  
And then you define one.
And then use it up .

Of course, anything that can cause CP to crash isn't a good thing.
Perhaps we need a dedicated paging area for CP, i.e. something like the DUMP 
area for CP dumps, instead of using SPOL.  The guest machines are still going 
to crash, and the offending machine will be the last of many machines to bite 
the dust.  But, CP would survive.  It might be easier to IPL to get everything 
back running again.

Tom Duerbusch
THD Consulting


>>> "Schuh, Richard"  9/15/2009 11:59 AM >>>
Maybe CP couldn't know that the guest would do something bad, but it should 
know that it has opened itself to the possibility that the guest could, in 
normal operation, cause the problem. 
One of Alan's first precepts of information security and integrity is that the 
guest cannot be allowed to harm the CP. This clearly violates that.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
> Sent: Tuesday, September 15, 2009 9:19 AM
> To: IBMVM@LISTSERV.UARK.EDU 
> Subject: Re: VM lockup due to storage typo
> 
> CP wouldn't know at IPL time, the guest would, not could, but 
> would cause such harm.
> 
> Just because you say you can use xxx GB, doesn't mean you 
> would actually use them.
> 
> When page fills, it over flows to spool.
> When spool fills, CP abends on the next pageout.
> 
> Tom Duerbusch
> THD Consulting
> 
> >>> Marcy Cortes  9/15/2009 
> 11:02 AM >>>
> See a thread on this list with subject "Sanity check?" from 
> Oct 2007 for what happened when I did the same thing ;)
> 
> You probably filled page space.
> 
> I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> Sent: Tuesday, September 15, 2009 8:39 AM
> To: IBMVM@LISTSERV.UARK.EDU 
> Subject: [IBMVM] VM lockup due to storage typo
> 
> Does anyone have an idea of how we might have gotten out of 
> this without an IPL?
> 
> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> Several guests needed more memory added so the directory was 
> updated and one by one the guests shutdown, logged off and 
> back on.  So far, so good.
> 
> But... In changing the memory for many guests, and it being 
> late at night after a long day, while meaning to set a 
> guest's memory to 9728M, it got set to 9728G.  When that 
> guest was cycled we see the message on the console that it's 
> memory was limited to 8TB (HCPLGN093E), then the VM system 
> appeared to freeze.
> 
> We couldn't get in via TCP/IP, or the HMC Operating System 
> Messages screen, or the HMC Integrated 3270.
> 
> Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
> and all came back up ok...
> 
> I suspect CP was scrambling paging everything in the world 
> out as Linux 
> tried to initialize that 8TB of memory...   But I'm surprised 
> I couldn't 
> even get into the HMC consoles (to kill just that one guest 
> as opposed to all of them)..
> 
> Any thoughts?
> Lee
> -- 
> 
> Lee Stewart, Senior SE
> Sirius Computer Solutions
> Phone: (303) 996-7122
> Email: lee.stew...@siriuscom.com 
> Web:   www.siriuscom.com 
> 

Re: VM lockup due to storage typo

[Schuh, Richard]

Maybe CP couldn't know that the guest would do something bad, but it should 
know that it has opened itself to the possibility that the guest could, in 
normal operation, cause the problem. 
One of Alan's first precepts of information security and integrity is that the 
guest cannot be allowed to harm the CP. This clearly violates that.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch
> Sent: Tuesday, September 15, 2009 9:19 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> CP wouldn't know at IPL time, the guest would, not could, but 
> would cause such harm.
> 
> Just because you say you can use xxx GB, doesn't mean you 
> would actually use them.
> 
> When page fills, it over flows to spool.
> When spool fills, CP abends on the next pageout.
> 
> Tom Duerbusch
> THD Consulting
> 
> >>> Marcy Cortes  9/15/2009 
> 11:02 AM >>>
> See a thread on this list with subject "Sanity check?" from 
> Oct 2007 for what happened when I did the same thing ;)
> 
> You probably filled page space.
> 
> I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> Sent: Tuesday, September 15, 2009 8:39 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: [IBMVM] VM lockup due to storage typo
> 
> Does anyone have an idea of how we might have gotten out of 
> this without an IPL?
> 
> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> Several guests needed more memory added so the directory was 
> updated and one by one the guests shutdown, logged off and 
> back on.  So far, so good.
> 
> But... In changing the memory for many guests, and it being 
> late at night after a long day, while meaning to set a 
> guest's memory to 9728M, it got set to 9728G.  When that 
> guest was cycled we see the message on the console that it's 
> memory was limited to 8TB (HCPLGN093E), then the VM system 
> appeared to freeze.
> 
> We couldn't get in via TCP/IP, or the HMC Operating System 
> Messages screen, or the HMC Integrated 3270.
> 
> Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
> and all came back up ok...
> 
> I suspect CP was scrambling paging everything in the world 
> out as Linux 
> tried to initialize that 8TB of memory...   But I'm surprised 
> I couldn't 
> even get into the HMC consoles (to kill just that one guest 
> as opposed to all of them)..
> 
> Any thoughts?
> Lee
> -- 
> 
> Lee Stewart, Senior SE
> Sirius Computer Solutions
> Phone: (303) 996-7122
> Email: lee.stew...@siriuscom.com 
> Web:   www.siriuscom.com
> 

Re: VM lockup due to storage typo

[Schuh, Richard]

This should be treated as a bug. It is not an enhancement or new feature, it 
brought a running system down. And it probably did not take a dump. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Daniel P. Martin
> Sent: Tuesday, September 15, 2009 9:09 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> *cough*SHARE requirement?*cough*
> 
> Marcy Cortes wrote:
> > See a thread on this list with subject "Sanity check?" from 
> Oct 2007 
> > for what happened when I did the same thing ;)
> >
> > You probably filled page space.
> >
> > I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> >
> >
> > Marcy
> >
> > "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> >
> >
> > -Original Message-
> > From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] 
> > On Behalf Of Lee Stewart
> > Sent: Tuesday, September 15, 2009 8:39 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: [IBMVM] VM lockup due to storage typo
> >
> > Does anyone have an idea of how we might have gotten out of this 
> > without an IPL?
> >
> > VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> > Several guests needed more memory added so the directory 
> was updated 
> > and one by one the guests shutdown, logged off and back on. 
>  So far, so good.
> >
> > But... In changing the memory for many guests, and it being late at 
> > night after a long day, while meaning to set a guest's memory to 
> > 9728M, it got set to 9728G.  When that guest was cycled we see the 
> > message on the console that it's memory was limited to 8TB 
> > (HCPLGN093E), then the VM system appeared to freeze.
> >
> > We couldn't get in via TCP/IP, or the HMC Operating System Messages 
> > screen, or the HMC Integrated 3270.
> >
> > Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> > Normal to shutdown, it just IPLed.   We did NoAutolog, 
> fixed the typo 
> > and all came back up ok...
> >
> > I suspect CP was scrambling paging everything in the world 
> out as Linux 
> > tried to initialize that 8TB of memory...   But I'm 
> surprised I couldn't 
> > even get into the HMC consoles (to kill just that one guest 
> as opposed 
> > to all of them)..
> >
> > Any thoughts?
> > Lee
> >   
> 

Re: VM lockup due to storage typo

[Daniel P. Martin]

*cough*SHARE requirement?*cough*

Marcy Cortes wrote:

See a thread on this list with subject "Sanity check?" from Oct 2007 for what 
happened when I did the same thing ;)

You probably filled page space.

I still think IBM should refuse to IPL a guest that will cause such harm.


Marcy 


"This message may contain confidential and/or privileged information. If you are not 
the addressee or authorized to receive this for the addressee, you must not use, copy, 
disclose, or take any action based on this message or any information herein. If you have 
received this message in error, please advise the sender immediately by reply e-mail and 
delete this message. Thank you for your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?


VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.


But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.


We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.


Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...


I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..


Any thoughts?
Lee
  

Re: VM lockup due to storage typo

[Schuh, Richard]

Both Page and Spool space!!! When you get to the end of spool, there is nothing 
further that can be done. This ought to be considered a bug. Surely CP has the 
information it needs to determine that the virtual storage size is way too big 
to be accommodated and should reject the logon. This ought to be reported. If 
the logon is not rejected, CP ought to keep enough storage in reserve so that 
the operator can still get in and force the offender. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes
> Sent: Tuesday, September 15, 2009 9:03 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> See a thread on this list with subject "Sanity check?" from 
> Oct 2007 for what happened when I did the same thing ;)
> 
> You probably filled page space.
> 
> I still think IBM should refuse to IPL a guest that will 
> cause such harm.
> 
> 
> Marcy 
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart
> Sent: Tuesday, September 15, 2009 8:39 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: [IBMVM] VM lockup due to storage typo
> 
> Does anyone have an idea of how we might have gotten out of 
> this without an IPL?
> 
> VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
> Several guests needed more memory added so the directory was 
> updated and one by one the guests shutdown, logged off and 
> back on.  So far, so good.
> 
> But... In changing the memory for many guests, and it being 
> late at night after a long day, while meaning to set a 
> guest's memory to 9728M, it got set to 9728G.  When that 
> guest was cycled we see the message on the console that it's 
> memory was limited to 8TB (HCPLGN093E), then the VM system 
> appeared to freeze.
> 
> We couldn't get in via TCP/IP, or the HMC Operating System 
> Messages screen, or the HMC Integrated 3270.
> 
> Finally had to IPL.   Even that was wierd as I'd have 
> expected the Load 
> Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
> and all came back up ok...
> 
> I suspect CP was scrambling paging everything in the world 
> out as Linux 
> tried to initialize that 8TB of memory...   But I'm surprised 
> I couldn't 
> even get into the HMC consoles (to kill just that one guest 
> as opposed to all of them)..
> 
> Any thoughts?
> Lee
> -- 
> 
> Lee Stewart, Senior SE
> Sirius Computer Solutions
> Phone: (303) 996-7122
> Email: lee.stew...@siriuscom.com
> Web:   www.siriuscom.com
> 

Re: VM lockup due to storage typo

[Tom Duerbusch]

CP wouldn't know at IPL time, the guest would, not could, but would cause such 
harm.

Just because you say you can use xxx GB, doesn't mean you would actually use 
them.

When page fills, it over flows to spool.
When spool fills, CP abends on the next pageout.

Tom Duerbusch
THD Consulting

>>> Marcy Cortes  9/15/2009 11:02 AM >>>
See a thread on this list with subject "Sanity check?" from Oct 2007 for what 
happened when I did the same thing ;)

You probably filled page space.

I still think IBM should refuse to IPL a guest that will cause such harm.


Marcy 

"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?

VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.

But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.

We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.

Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...

I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..

Any thoughts?
Lee
-- 

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com 
Web:   www.siriuscom.com

Re: VM lockup due to storage typo

[Lee Stewart]

No ESM (yet)...  Operator and Maint both have QUICKDSP, the Linux guests 
do NOT have it...

Lee

O'Brien, Dennis L wrote:

Lee,
Do the userid you were trying to log onto and your external security manager 
both have OPTION QUICKDSP in the directory?  Your operator userid should also 
have QUICKDSP.

 Dennis O'Brien

My computer beat me at chess, but it was no match for me in kickboxing.

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 08:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?


VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.


But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.


We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.


Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...


I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..


Any thoughts?
Lee


--

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com
Web:   www.siriuscom.com

Re: PPRC commands under z/VM

[Florian Bilek]

Hi Kris, 

Thank you. That would be great. 

Kind regards, 
Fox

Re: VM lockup due to storage typo

[O'Brien, Dennis L]

Lee,
Do the userid you were trying to log onto and your external security manager 
both have OPTION QUICKDSP in the directory?  Your operator userid should also 
have QUICKDSP.

         Dennis O'Brien

My computer beat me at chess, but it was no match for me in kickboxing.

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 08:39
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?

VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.

But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.

We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.

Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...

I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..

Any thoughts?
Lee
-- 

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com
Web:   www.siriuscom.com

Re: VM lockup due to storage typo

[Marcy Cortes]

See a thread on this list with subject "Sanity check?" from Oct 2007 for what 
happened when I did the same thing ;)

You probably filled page space.

I still think IBM should refuse to IPL a guest that will cause such harm.


Marcy 

"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Lee Stewart
Sent: Tuesday, September 15, 2009 8:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM lockup due to storage typo

Does anyone have an idea of how we might have gotten out of this without 
an IPL?

VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.

But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.

We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.

Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...

I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..

Any thoughts?
Lee
-- 

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com
Web:   www.siriuscom.com

Re: PPRC commands under z/VM

[Kris Buelens]

You need to use ICKDSF, PPRC ESTPATH and PPRC ESTPAIR commands.   I can dig
up some execs that help a bit.

2009/9/15 Florian Bilek 

> Dear all,
>
> I need to establish several PPRC pairs between two DS-8000 at our local
> site for our z/VM system.
>
> There is a lot of information around about this matter but unfortunately it
> is still not totally clear to me, if there are native z/VM commands for
> manageing the PPRC pairs or do I need to use ICKDSF to achieve this.
> Referring to the DUPLEX command I find it ambigous what is stated there as
> it referes to " 3990-3 and 3990-6" controllers only. Would be nice to have
> some reference regarding PPRC, clarifying that this is not for DS-8000 PPRC.
>
>
> I would like to prepare scripts that establish or break the pairing if
> necessary.
>
> Thank you very much in advance.
> Kind regards,
> Fox
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Problem that is a blast from the past...

[Kris Buelens]

Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a
server I'd say: you'd use it to separate what you place in the stack from
what is there already, but as you code DROPBUF 0, there is surely nothing
anymore to separate your stuff from.

2009/9/15 Schuh, Richard 

>  Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last
> buffer created is dropped; 0 implies all buffers, not just the last. A
> sequence of
>
> 'DROPBUF 0'
> MAKEBUF'
> 'WAKEUP ...'
>
> might be preferable if you are unsure of what called routines might have
> done.
>
>
> Regards,
> Richard Schuh
>
>
>
>
>  --
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Kris Buelens
> *Sent:* Monday, September 14, 2009 11:40 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: Problem that is a blast from the past...
>
> When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also
> clears CMS' console output buffer.
> In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I
> didn't see all executed lines.  I was almost convinced that I found a bug in
> EXEC1 as in the console trace I saw it jump from exec line xxx to yyy
> without an &GOTO to explain the jump...  But, you guessed it: at line yyy-1
> there was a DESBUF...
> In my experience, DESBUF is no longer of any use since the arrival of
> DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2.
> So, in a bigger WAKEUP based server, where one isn't sure some other called
> exec leaves stacked lines behind, it might be better to code
>   'DROPBUF'
>   'WAKEUP .'  with or without CONS, it wouldn't matter anymore.
>
> 2009/9/14 Colleen Brown 
>
>>
>> I really think Kris's first response about the CONS option is the correct
>> one.  You don't want to use this option unless you have some specific need.
>>  WAKEUP will wake and give a rc 6 when you hit enter on the console without
>> this option.  I have done traces before and 'watched' the rc 6 occur because
>> of something being put temporarily on the stack by CMS.  In those cases
>> WAKEUP is too efficient and catches what you don't want caught.
>> Another quirky thing with WAKEUP is using DESBUF without CONWAIT.  DROPBUF
>> works much better with WAKEUP and isn't as finicky about whether or not
>> CONWAIT is used.
>> (It has been too long since I chased some of these things.  Memory fades
>> ...)
>>
>> Colleen M Brown
>> IBM z/VM and Related Products Development and Service
>>
>>
>>   *Kris Buelens *
>> Sent by: The IBM z/VM Operating System 
>>
>> 09/14/2009 04:03 PM
>>   Please respond to
>> The IBM z/VM Operating System 
>>
>>To
>> IBMVM@LISTSERV.UARK.EDU  cc
>>   Subject
>> Re: Problem that is a blast from the past...
>>
>>
>>
>>
>> As far as I know: CP FOR can only be used to execute CP commands on behalf
>> of the target user, it does not generate console interrupts as opposed to CP
>> SEND.
>>
>> 2009/9/14 Mike Walter <*mike.wal...@hewitt.com* >
>> Is there any chance of some other SVM issuing a 'CP SEND' or 'CP FOR'
>> command to the server running WAKEUP and experiencing the unexpected
>> interrupt?
>>
>> Of course, in such a case of one disconnected SVM waking another up in
>> that manner, one might expect to hear the faint strains of "Dueling
>> Banjos" playing softly in the background!  ;-)
>>
>> Mike Walter
>> Hewitt Associates
>> The opinions expressed herein are mine alone, not my employer's.
>>
>>
>>
>>
>>
>> --
>> Kris Buelens,
>> IBM Belgium, VM customer support
>>
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Problem that is a blast from the past...

[Colleen Brown]

You all have great memories!  I didn't mean to imply a current problem 
with DESBUF versus DROPBUF.  I was just recalling other 'quirkiness' when 
using WAKEUP.  This DESBUF versus DROPBUF thing is not isolated to just 
execs using WAKEUP.  However, because of WAKEUP's fielding of interrupts 
you can see results you didn't expect.  And yes, it is better to specify a 
number with DROPBUF with 0 meaning all the program stack buffers.

Colleen M Brown 
IBM z/VM and Related Products Development and Service 



"Schuh, Richard"  
Sent by: The IBM z/VM Operating System 
09/15/2009 11:36 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Problem that is a blast from the past...






Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last 
buffer created is dropped; 0 implies all buffers, not just the last. A 
sequence of
 
'DROPBUF 0'
MAKEBUF'
'WAKEUP ...'
 
might be preferable if you are unsure of what called routines might have 
done.
 
Regards, 
Richard Schuh 
 
 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Kris Buelens
Sent: Monday, September 14, 2009 11:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Problem that is a blast from the past...

When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also 
clears CMS' console output buffer. 
In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I 
didn't see all executed lines.  I was almost convinced that I found a bug 
in EXEC1 as in the console trace I saw it jump from exec line xxx to yyy 
without an &GOTO to explain the jump...  But, you guessed it: at line 
yyy-1 there was a DESBUF...
In my experience, DESBUF is no longer of any use since the arrival of 
DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2.
So, in a bigger WAKEUP based server, where one isn't sure some other 
called exec leaves stacked lines behind, it might be better to code
  'DROPBUF'
  'WAKEUP .'  with or without CONS, it wouldn't matter anymore.

2009/9/14 Colleen Brown 

I really think Kris's first response about the CONS option is the correct 
one.  You don't want to use this option unless you have some specific 
need.  WAKEUP will wake and give a rc 6 when you hit enter on the console 
without this option.  I have done traces before and 'watched' the rc 6 
occur because of something being put temporarily on the stack by CMS.  In 
those cases WAKEUP is too efficient and catches what you don't want 
caught.   
Another quirky thing with WAKEUP is using DESBUF without CONWAIT.  DROPBUF 
works much better with WAKEUP and isn't as finicky about whether or not 
CONWAIT is used. 
(It has been too long since I chased some of these things.  Memory fades 
...) 

Colleen M Brown 
IBM z/VM and Related Products Development and Service 


Kris Buelens  
Sent by: The IBM z/VM Operating System  
09/14/2009 04:03 PM 


Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Re: Problem that is a blast from the past...








As far as I know: CP FOR can only be used to execute CP commands on behalf 
of the target user, it does not generate console interrupts as opposed to 
CP SEND.

2009/9/14 Mike Walter  
Is there any chance of some other SVM issuing a 'CP SEND' or 'CP FOR'
command to the server running WAKEUP and experiencing the unexpected
interrupt?

Of course, in such a case of one disconnected SVM waking another up in
that manner, one might expect to hear the faint strains of "Dueling
Banjos" playing softly in the background!  ;-)

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





-- 
Kris Buelens,
IBM Belgium, VM customer support 



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Printers to 2nd level VM...

[Tom Duerbusch]

Yep, that is what he said...
And as I don't trust computers, you know I never trust people .

If it isn't that, then the printers need to be attached to the second level 
system during the IPL of the second level system.  

In my experience, printers don't sense too well.
If you IPL with the printers attached, and it still doesn't sense properly, 
perhaps there is a SET RDEVICE in the autolog process, or in the Operators 
profile.

But, if this volume was truely cloned, all that should be there.
So that brings me back to IPL with the devices attached and see what you get.  
Or at least attach one of them for testing.

The other thing that may be different with a second level system, is if you are 
doing the same saipl that you are in hardware.  Sometimes you forget that the 
hardware IPL, may be accessing a different disk than CF1.

Tom Duerbusch
THD Consulting

>>> Robert Payne  9/15/2009 10:28 AM >>>
but I thought he said that he cloned the volumes, so the CONFIG should already 
be in place ...


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on 
Behalf Of Tom Duerbusch
Sent: Tuesday, September 15, 2009 10:26 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: Printers to 2nd level VM...


You have to define the printers to your second level VM system.
... big snip

VM lockup due to storage typo

[Lee Stewart]

Does anyone have an idea of how we might have gotten out of this without 
an IPL?


VM LPAR has 175G of memory and a flock of Linux Oracle guests... 
Several guests needed more memory added so the directory was updated and 
one by one the guests shutdown, logged off and back on.  So far, so good.


But... In changing the memory for many guests, and it being late at 
night after a long day, while meaning to set a guest's memory to 9728M, 
it got set to 9728G.  When that guest was cycled we see the message on 
the console that it's memory was limited to 8TB (HCPLGN093E), then the 
VM system appeared to freeze.


We couldn't get in via TCP/IP, or the HMC Operating System Messages 
screen, or the HMC Integrated 3270.


Finally had to IPL.   Even that was wierd as I'd have expected the Load 
Normal to shutdown, it just IPLed.   We did NoAutolog, fixed the typo 
and all came back up ok...


I suspect CP was scrambling paging everything in the world out as Linux 
tried to initialize that 8TB of memory...   But I'm surprised I couldn't 
even get into the HMC consoles (to kill just that one guest as opposed 
to all of them)..


Any thoughts?
Lee
--

Lee Stewart, Senior SE
Sirius Computer Solutions
Phone: (303) 996-7122
Email: lee.stew...@siriuscom.com
Web:   www.siriuscom.com

Re: Problem that is a blast from the past...

[Schuh, Richard]

Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last buffer 
created is dropped; 0 implies all buffers, not just the last. A sequence of

'DROPBUF 0'
MAKEBUF'
'WAKEUP ...'

might be preferable if you are unsure of what called routines might have done.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Kris Buelens
Sent: Monday, September 14, 2009 11:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Problem that is a blast from the past...

When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also clears 
CMS' console output buffer.
In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I 
didn't see all executed lines.  I was almost convinced that I found a bug in 
EXEC1 as in the console trace I saw it jump from exec line xxx to yyy without 
an &GOTO to explain the jump...  But, you guessed it: at line yyy-1 there was a 
DESBUF...
In my experience, DESBUF is no longer of any use since the arrival of DROPBUF, 
and that was together with EXEC2, maybe in VM/SP Rel 2.
So, in a bigger WAKEUP based server, where one isn't sure some other called 
exec leaves stacked lines behind, it might be better to code
  'DROPBUF'
  'WAKEUP .'  with or without CONS, it wouldn't matter anymore.

2009/9/14 Colleen Brown mailto:brown...@us.ibm.com>>

I really think Kris's first response about the CONS option is the correct one.  
You don't want to use this option unless you have some specific need.  WAKEUP 
will wake and give a rc 6 when you hit enter on the console without this 
option.  I have done traces before and 'watched' the rc 6 occur because of 
something being put temporarily on the stack by CMS.  In those cases WAKEUP is 
too efficient and catches what you don't want caught.
Another quirky thing with WAKEUP is using DESBUF without CONWAIT.  DROPBUF 
works much better with WAKEUP and isn't as finicky about whether or not CONWAIT 
is used.
(It has been too long since I chased some of these things.  Memory fades ...)

Colleen M Brown
IBM z/VM and Related Products Development and Service


Kris Buelens mailto:kris.buel...@gmail.com>>
Sent by: The IBM z/VM Operating System 
mailto:IBMVM@LISTSERV.UARK.EDU>>

09/14/2009 04:03 PM

Please respond to
The IBM z/VM Operating System 
mailto:IBMVM@LISTSERV.UARK.EDU>>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Problem that is a blast from the past...







As far as I know: CP FOR can only be used to execute CP commands on behalf of 
the target user, it does not generate console interrupts as opposed to CP SEND.

2009/9/14 Mike Walter mailto:mike.wal...@hewitt.com>>
Is there any chance of some other SVM issuing a 'CP SEND' or 'CP FOR'
command to the server running WAKEUP and experiencing the unexpected
interrupt?

Of course, in such a case of one disconnected SVM waking another up in
that manner, one might expect to hear the faint strains of "Dueling
Banjos" playing softly in the background!  ;-)

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





--
Kris Buelens,
IBM Belgium, VM customer support



--
Kris Buelens,
IBM Belgium, VM customer support

Re: Printers to 2nd level VM...

[Robert Payne]

but I thought he said that he cloned the volumes, so the CONFIG should already 
be in place ...


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on
Behalf Of Tom Duerbusch
Sent: Tuesday, September 15, 2009 10:26 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Printers to 2nd level VM...


You have to define the printers to your second level VM system.
... big snip

Re: Printers to 2nd level VM...

[Tom Duerbusch]

You have to define the printers to your second level VM system.

My guess is that you also had to define them on the first level system.
Look at the SYSTEM CONFIG on the first level to see if you have a RDEVICE 
similar to:

RDEVICE  00E TYPE  IMPACT_PRINTER,   
   CLASSES S,
   FOLDUP YES,   
   IMAGE_LIB IMAG3262
 
RDEVICE  00F TYPE  IMPACT_PRINTER,   
   CLASSES A 
 
RDEVICE  01E TYPE  IMPACT_PRINTER,   
   CLASSES F,
   FOLDUP YES,   
   IMAGE_LIB IMAG4248

And then copy it to the second level SYSTEM CONFIG.

Tom Duerbusch
THD Consulting

>>> Robert Payne  9/15/2009 10:05 AM >>>
and I guess the "FORCE" option doesn't help ?
Darn the bad luck! Sorry but I'm out of ideas for now.
Bubba



-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on 
Behalf Of Frank M. Ramaekers
Sent: Tuesday, September 15, 2009 9:28 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: Printers to 2nd level VM...


Can do, but...

set rdevice 5336-5338 ty imp  
HCPZRP6722I Characteristics of device 5336 were set as requested. 
HCPZRP6722I Characteristics of device 5337 were set as requested. 
HCPZRP6722I Characteristics of device 5338 were set as requested. 
3 RDEV(s) specified; 3 RDEV(s) changed; 0 RDEV(s) created 
Ready; T=0.01/0.01 09:27:15   
q 5336-5338   
PRT  5336 OFFLINE , PRT  5337 OFFLINE , PRT  5338 OFFLINE 
Ready; T=0.01/0.01 09:27:22   
vary on 5336-5338 
HCPCPN6895I Device 5336 cannot be varied online because the device
HCPCPN6895I identification data is inconclusive.  
H

Re: Printers to 2nd level VM...

[Robert Payne]

and I guess the "FORCE" option doesn't help ?
Darn the bad luck! Sorry but I'm out of ideas for now.
Bubba



-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on
Behalf Of Frank M. Ramaekers
Sent: Tuesday, September 15, 2009 9:28 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Printers to 2nd level VM...


Can do, but...

set rdevice 5336-5338 ty imp  
HCPZRP6722I Characteristics of device 5336 were set as requested. 
HCPZRP6722I Characteristics of device 5337 were set as requested. 
HCPZRP6722I Characteristics of device 5338 were set as requested. 
3 RDEV(s) specified; 3 RDEV(s) changed; 0 RDEV(s) created 
Ready; T=0.01/0.01 09:27:15   
q 5336-5338   
PRT  5336 OFFLINE , PRT  5337 OFFLINE , PRT  5338 OFFLINE 
Ready; T=0.01/0.01 09:27:22   
vary on 5336-5338 
HCPCPN6895I Device 5336 cannot be varied online because the device
HCPCPN6895I identification data is inconclusive.  
H

PPRC commands under z/VM

[Florian Bilek]

Dear all,

I need to establish several PPRC pairs between two DS-8000 at our local site
for our z/VM system.

There is a lot of information around about this matter but unfortunately it
is still not totally clear to me, if there are native z/VM commands for
manageing the PPRC pairs or do I need to use ICKDSF to achieve this.
Referring to the DUPLEX command I find it ambigous what is stated there as
it referes to " 3990-3 and 3990-6" controllers only. Would be nice to have
some reference regarding PPRC, clarifying that this is not for DS-8000 PPRC.


I would like to prepare scripts that establish or break the pairing if
necessary.

Thank you very much in advance.
Kind regards,
Fox

Re: Pascal Runtime in z/vm????

[Alan Altmark]

On Tuesday, 09/15/2009 at 09:59 EDT, Edward M Martin  
wrote:
> Yep I have a TCPASCAL TXTLIB   Q2  on TCPMAINT 592 disk with 310 ENTRIES 
IN 
> LIBRARY.

The Pascal RTL for IBM-supplied application and server programs is 
TCPRTLIB LOADLIB on TCPMAINT 592.

Alan Altmark
z/VM Development
IBM Endicott

Re: Printers to 2nd level VM...

[Frank M. Ramaekers]

Can do, but...

set rdevice 5336-5338 ty imp  
HCPZRP6722I Characteristics of device 5336 were set as requested. 
HCPZRP6722I Characteristics of device 5337 were set as requested. 
HCPZRP6722I Characteristics of device 5338 were set as requested. 
3 RDEV(s) specified; 3 RDEV(s) changed; 0 RDEV(s) created 
Ready; T=0.01/0.01 09:27:15   
q 5336-5338   
PRT  5336 OFFLINE , PRT  5337 OFFLINE , PRT  5338 OFFLINE 
Ready; T=0.01/0.01 09:27:22   
vary on 5336-5338 
HCPCPN6895I Device 5336 cannot be varied online because the device
HCPCPN6895I identification data is inconclusive.  
HCPCPN6785E Unable to identify device 5336 dynamically.   
HCPCPN6895I Device 5337 cannot be varied online because the device
HCPCPN6895I identification data is inconclusive.  
HCPCPN6785E Unable to identify device 5337 dynamically.   
HCPCPN6895I Device 5338 cannot be varied online because the device
HCPCPN6895I identification data is inconclusive.  
HCPCPN6785E Unable to identify device 5338 dynamically.   
3 device(s) specified; 0 device(s) successfully varied online 
Ready(06785); T=0.01/0.01 09:27:30

Frank M. Ramaekers Jr.
Systems Programmer   MCP, MCP+I, MCSE & RHCE
American Income Life Insurance Co.   Phone: (254)761-6649
1200 Wooded Acres Dr.Fax:   (254)741-5777
Waco, Texas  76710


 


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Robert Payne
Sent: Tuesday, September 15, 2009 8:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Printers to 2nd level VM...

Can you SET RDEVICE ?

 


  
vary on 5336-5338  
HCPCPN6895I Device 5336 cannot be varied online because the device 
HCPCPN6895I identification data is inconclusive.   

_
This message contains information which is privileged and confidential and is 
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,
copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have
received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Re: Pascal Runtime in z/vm????

[Alan Altmark]

On Tuesday, 09/15/2009 at 04:31 EDT, Victor Hugo Ochoa  
wrote:

> In z/VM 5.3:
> somebody can indicate to me in that Minidisk and in which VM user I can
> find the Pascal Runtime code???

Your question confuses me a bit, Victor.  If you have access to the 
IBM-supplied programs that need the Pascal RTL, then you also have access 
to the Pascal RTL, as all of them are located on the same disk, TCPMAINT 
592.

Are you getting an error message?

Alan Altmark
z/VM Development
IBM Endicott

Re: Printers to 2nd level VM...

[Frank M. Ramaekers]

If so, then they'd propagate to the 2nd level (2nd level was
FLASHCOPY'ed from first level).  (Since the address weren't changed, see
DEDICATEs in original email.)

Frank M. Ramaekers Jr.
Systems Programmer   MCP, MCP+I, MCSE & RHCE
American Income Life Insurance Co.   Phone: (254)761-6649
1200 Wooded Acres Dr.Fax:   (254)741-5777
Waco, Texas  76710

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Alan Altmark
Sent: Tuesday, September 15, 2009 8:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Printers to 2nd level VM...

On Tuesday, 09/15/2009 at 09:44 EDT, "Frank M. Ramaekers" 
 wrote:

> After 2nd level is brought up:
> 
> From 1st level:
> 
> q 5336-5338
> PRT 5336 ATTACHED TO VM2ND5336
> PRT 5337 ATTACHED TO VM2ND5337
> PRT 5338 ATTACHED TO VM2ND5338
> 
> From 2nd level:
> 
> q 5336-5338
> DEV  5336 OFFLINE , DEV  5337 OFFLINE , DEV  5338 OFFLINE
> Ready; T=0.01/0.01 08:42:24
> vary on 5336-5338
> HCPCPN6895I Device 5336 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5336 dynamically.
> HCPCPN6895I Device 5337 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5337 dynamically.
> HCPCPN6895I Device 5338 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5338 dynamically.
> 3 device(s) specified; 0 device(s) successfully varied online
> Ready(06785); T=0.01/0.01 08:42:46
> 
> I don't see why I can't bring these devices online 2nd level.

I suspect that your 1st level SYSTEM CONFIG has RDEVICE entries that 
define these devices as printers.  Copy those same entries to your 2nd 
level SYSTEM CONFIG.

Alan Altmark
z/VM Development
IBM Endicott

_
This message contains information which is privileged and confidential and is 
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,
copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have
received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Re: Pascal Runtime in z/vm????

[Edward M Martin]

Yep I have a TCPASCAL TXTLIB   Q2  on TCPMAINT 592 disk with 310 ENTRIES
IN LIBRARY.

 

Ed Martin

Aultman Health Foundation

330-363-5050

ext 35050

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Kris Buelens
Sent: Tuesday, September 15, 2009 5:50 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Pascal Runtime in z/vm

 

As parts of TCPIP were written in Pascal, you might try TCPMAINT 591
and/or 592

2009/9/15 =?ISO-8859-1?Q?Victor_Hugo_Ochoa?= 

Hi Hello to all.

In z/VM 5.3:

somebody can indicate to me in that Minidisk and in which VM user I can
find
the Pascal Runtime code???

greetings and thanks




-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Printers to 2nd level VM...

[Alan Altmark]

On Tuesday, 09/15/2009 at 09:44 EDT, "Frank M. Ramaekers" 
 wrote:

> After 2nd level is brought up:
> 
> From 1st level:
> 
> q 5336-5338
> PRT 5336 ATTACHED TO VM2ND5336
> PRT 5337 ATTACHED TO VM2ND5337
> PRT 5338 ATTACHED TO VM2ND5338
> 
> From 2nd level:
> 
> q 5336-5338
> DEV  5336 OFFLINE , DEV  5337 OFFLINE , DEV  5338 OFFLINE
> Ready; T=0.01/0.01 08:42:24
> vary on 5336-5338
> HCPCPN6895I Device 5336 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5336 dynamically.
> HCPCPN6895I Device 5337 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5337 dynamically.
> HCPCPN6895I Device 5338 cannot be varied online because the device
> HCPCPN6895I identification data is inconclusive.
> HCPCPN6785E Unable to identify device 5338 dynamically.
> 3 device(s) specified; 0 device(s) successfully varied online
> Ready(06785); T=0.01/0.01 08:42:46
> 
> I don't see why I can't bring these devices online 2nd level.

I suspect that your 1st level SYSTEM CONFIG has RDEVICE entries that 
define these devices as printers.  Copy those same entries to your 2nd 
level SYSTEM CONFIG.

Alan Altmark
z/VM Development
IBM Endicott

Re: Printers to 2nd level VM...

[Robert Payne]

Can you SET RDEVICE ?

 


  
vary on 5336-5338  
HCPCPN6895I Device 5336 cannot be varied online because the device 
HCPCPN6895I identification data is inconclusive.   

Printers to 2nd level VM...

[Frank M. Ramaekers]

...won't come online.

1st level (before 2nd level is brought up):

q 5336-5338  
PRT  5336 DRAINEDSYSTEM   CLASS A
PRT  5336 FORM STANDARD MANUAL SEP   NO3800  FILEFCB LIMIT NONE  
PRT  5336 NOFOLD  IMAGE IMAG3211 CHARS A11  FCB FCB1 INDEX 1  LPP 000
PRT  5336 DEST OFF  DEST - NONE - DEST - NONE - DEST - NONE -
PRT  5336 AFP
PRT  5337 DRAINEDSYSTEM   CLASS A
PRT  5337 FORM STANDARD MANUAL SEP   NO3800  FILEFCB LIMIT NONE  
PRT  5337 NOFOLD  IMAGE IMAG3211 CHARS A11  FCB FCB1 INDEX 1  LPP 000
PRT  5337 DEST OFF  DEST - NONE - DEST - NONE - DEST - NONE -
PRT  5337 AFP
PRT  5338 DRAINEDSYSTEM   CLASS A
PRT  5338 FORM STANDARD MANUAL SEP   NO3800  FILEFCB LIMIT NONE  
PRT  5338 NOFOLD  IMAGE IMAG3211 CHARS A11  FCB FCB1 INDEX 1  LPP 000
PRT  5338 DEST OFF  DEST - NONE - DEST - NONE - DEST - NONE -
PRT  5338 AFP
Ready; T=0.01/0.01 08:35:08  

Directory for 2nd level:

DEDICATE 5336 5336
 DEDICATE 5337 5337
 DEDICATE 5338 5338
-
After 2nd level is brought up:

From 1st level:

q 5336-5338   
PRT 5336 ATTACHED TO VM2ND5336
PRT 5337 ATTACHED TO VM2ND5337
PRT 5338 ATTACHED TO VM2ND5338

From 2nd level:

q 5336-5338
DEV  5336 OFFLINE , DEV  5337 OFFLINE , DEV  5338 OFFLINE  
Ready; T=0.01/0.01 08:42:24
vary on 5336-5338  
HCPCPN6895I Device 5336 cannot be varied online because the device 
HCPCPN6895I identification data is inconclusive.   
HCPCPN6785E Unable to identify device 5336 dynamically.
HCPCPN6895I Device 5337 cannot be varied online because the device 
HCPCPN6895I identification data is inconclusive.   
HCPCPN6785E Unable to identify device 5337 dynamically.
HCPCPN6895I Device 5338 cannot be varied online because the device 
HCPCPN6895I identification data is inconclusive.   
HCPCPN6785E Unable to identify device 5338 dynamically.
3 device(s) specified; 0 device(s) successfully varied online  
Ready(06785); T=0.01/0.01 08:42:46 

I don't see why I can't bring these devices online 2nd level.

Frank M. Ramaekers Jr.
Systems Programmer   MCP, MCP+I, MCSE & RHCE
American Income Life Insurance Co.   Phone: (254)761-6649
1200 Wooded Acres Dr.Fax:   (254)741-5777
Waco, Texas  76710


 


_
This message contains information which is privileged and confidential and is 
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,
copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have
received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Re: Pascal Runtime in z/vm????

[Kris Buelens]

As parts of TCPIP were written in Pascal, you might try TCPMAINT 591 and/or
592

2009/9/15 =?ISO-8859-1?Q?Victor_Hugo_Ochoa?= 

> Hi Hello to all.
>
> In z/VM 5.3:
>
> somebody can indicate to me in that Minidisk and in which VM user I can
> find
> the Pascal Runtime code???
>
> greetings and thanks
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Pascal Runtime in z/vm????

[=?ISO-8859-1?Q?Victor_Hugo_Ochoa?=]

Hi Hello to all.

In z/VM 5.3:

somebody can indicate to me in that Minidisk and in which VM user I can f
ind
the Pascal Runtime code???

greetings and thanks

Re: Problem that is a blast from the past...

[Kris Buelens]

When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also
clears CMS' console output buffer.
In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I
didn't see all executed lines.  I was almost convinced that I found a bug in
EXEC1 as in the console trace I saw it jump from exec line xxx to yyy
without an &GOTO to explain the jump...  But, you guessed it: at line yyy-1
there was a DESBUF...
In my experience, DESBUF is no longer of any use since the arrival of
DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2.
So, in a bigger WAKEUP based server, where one isn't sure some other called
exec leaves stacked lines behind, it might be better to code
  'DROPBUF'
  'WAKEUP .'  with or without CONS, it wouldn't matter anymore.

2009/9/14 Colleen Brown 

>
> I really think Kris's first response about the CONS option is the correct
> one.  You don't want to use this option unless you have some specific need.
>  WAKEUP will wake and give a rc 6 when you hit enter on the console without
> this option.  I have done traces before and 'watched' the rc 6 occur because
> of something being put temporarily on the stack by CMS.  In those cases
> WAKEUP is too efficient and catches what you don't want caught.
> Another quirky thing with WAKEUP is using DESBUF without CONWAIT.  DROPBUF
> works much better with WAKEUP and isn't as finicky about whether or not
> CONWAIT is used.
> (It has been too long since I chased some of these things.  Memory fades
> ...)
>
> Colleen M Brown
> IBM z/VM and Related Products Development and Service
>
>
>  *Kris Buelens *
> Sent by: The IBM z/VM Operating System 
>
> 09/14/2009 04:03 PM
>  Please respond to
> The IBM z/VM Operating System 
>
>   To
> IBMVM@LISTSERV.UARK.EDU  cc
>   Subject
> Re: Problem that is a blast from the past...
>
>
>
>
> As far as I know: CP FOR can only be used to execute CP commands on behalf
> of the target user, it does not generate console interrupts as opposed to CP
> SEND.
>
> 2009/9/14 Mike Walter <*mike.wal...@hewitt.com* >
> Is there any chance of some other SVM issuing a 'CP SEND' or 'CP FOR'
> command to the server running WAKEUP and experiencing the unexpected
> interrupt?
>
> Of course, in such a case of one disconnected SVM waking another up in
> that manner, one might expect to hear the faint strains of "Dueling
> Banjos" playing softly in the background!  ;-)
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
>
>
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>



-- 
Kris Buelens,
IBM Belgium, VM customer support