Re: TDISK and SYSTEM CONFIG question.

[Alan Altmark]

On Wednesday, 09/16/2009 at 07:14 EDT, "Gentry, Stephen" 
 wrote:

> Further, and in the same manual,  it states that you can clear each 
T-DISK 
> before it is reassigned.  It depends on your point of view but this 
seems 
> contradictory. Clear, in my opinion, means the T-DISK created with the 
DEFINE 
> command is completely cleared. Of course clearing cylinder 0, in effect, 
makes 
> the area unreadable.  Also one section of the manual seems to say that 
the area 
> is cleared at IPL time, the other section seems to say it is cleared 
before it 
> is reassigned.

Clearing cyl 0 only does not prevent you from reading the other cyls on 
the volume; it simply stops you from mounting it in the "usual" fashion.

The z/VM Secure Configuration Guide tells you to enable CLEAR_TDISK in 
SYSTEM CONFIG.  If you configure your system much the way it is described 
in that book, your auditor won't have any arguments with you.

Alan Altmark
z/VM Development
IBM Endicott

Re: TDISK and SYSTEM CONFIG question.

[O'Brien, Dennis L]

Stephen,

If you Enable the Clear_Tdisk feature, all system T-disk space is
cleared at IPL time the entire T-disk is cleared when it's detached, and
if you attach a new T-disk volume to SYSTEM, all space on that volume is
cleared.  Turn on the feature, IPL, then detach one of your T-disk
volumes from SYSTEM and reattach it.  Immediately enter Q ALLOC TDISK
and you'll see that all space is in use.  Issue it a few times over the
next minute or two, and you'll see the space free up as it's cleared.

 

 Dennis O'Brien

 

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

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Gentry, Stephen
Sent: Wednesday, September 16, 2009 14:10
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] TDISK and SYSTEM CONFIG question.

 

There is an option in the SYSTEM CONFIG file to clear the T-DISK.  It is
in the FEATURES list and CLEAR_TDISK can be either ENABLED or DISABLED.


The manual states that it clears only cylinder 0 (zero) or the first
eight blocks on the temporary minidisk when it detaches the minidisk. Do
they mean the minidisk that is created with the DEFINE statement or is
it the T-DISK area that gets cylinder 0 or first 8 blocks cleared?

Further, and in the same manual,  it states that you can clear each
T-DISK before it is reassigned.  It depends on your point of view but
this seems contradictory. Clear, in my opinion, means the T-DISK created
with the DEFINE command is completely cleared. Of course clearing
cylinder 0, in effect, makes the area unreadable.  Also one section of
the manual seems to say that the area is cleared at IPL time, the other
section seems to say it is cleared before it is reassigned.

I'm not trying to point out discrepancies in the manual, I'm curious as
to why it was originally needed and when does it actually get cleared.

(An external auditor is really hung up on this area not being cleared.)

Thanks,

Steve

TDISK and SYSTEM CONFIG question.

[Gentry, Stephen]

There is an option in the SYSTEM CONFIG file to clear the T-DISK.  It is
in the FEATURES list and CLEAR_TDISK can be either ENABLED or DISABLED.


The manual states that it clears only cylinder 0 (zero) or the first
eight blocks on the temporary minidisk when it detaches the minidisk. Do
they mean the minidisk that is created with the DEFINE statement or is
it the T-DISK area that gets cylinder 0 or first 8 blocks cleared?

Further, and in the same manual,  it states that you can clear each
T-DISK before it is reassigned.  It depends on your point of view but
this seems contradictory. Clear, in my opinion, means the T-DISK created
with the DEFINE command is completely cleared. Of course clearing
cylinder 0, in effect, makes the area unreadable.  Also one section of
the manual seems to say that the area is cleared at IPL time, the other
section seems to say it is cleared before it is reassigned.

I'm not trying to point out discrepancies in the manual, I'm curious as
to why it was originally needed and when does it actually get cleared.

(An external auditor is really hung up on this area not being cleared.)

Thanks,

Steve

Re: VM lockup due to storage typo

[Ron Schmiedge]

Unless you set MAXSTORAGE in the profile and used * as the upper limit
in the USER entry. Then if you change the lower limit to be higher
than the setting in the profile, you get an error.

On Wed, Sep 16, 2009 at 3:48 PM, Lee Stewart
 wrote:
> Not really as we were dealing with a lot of guests.  So the only practical
> place to put it would be in a profile.  But according to usage note #1:  A
> maximum storage setting on a USER statement overrides a MAXSTORAGE statement
> in a profile.
>
> So it would have no effect...
>
> Lee
>
> Ron Schmiedge wrote:
>>
>> I've been trying to follow the discussion and wondering if the
>> directory control statement
>>
>> MAXSTORAGE
>>
>> would have provided some protection from the finger check problem?
>
> --
>
> 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]

Not really as we were dealing with a lot of guests.  So the only 
practical place to put it would be in a profile.  But according to usage 
note #1:  A maximum storage setting on a USER statement overrides a 
MAXSTORAGE statement in a profile.


So it would have no effect...

Lee

Ron Schmiedge wrote:

I've been trying to follow the discussion and wondering if the
directory control statement

MAXSTORAGE

would have provided some protection from the finger check problem?


--

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]

Only if it were included in every directory entry, or at least the one in 
question. Having a global MAXSTORAGE would be better protection.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Ron Schmiedge
> Sent: Wednesday, September 16, 2009 2:20 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> I've been trying to follow the discussion and wondering if 
> the directory control statement
> 
> MAXSTORAGE
> 
> would have provided some protection from the finger check problem?
> 
> 
> 
> On Wed, Sep 16, 2009 at 2:59 PM, Alan Altmark 
>  wrote:
> > On Wednesday, 09/16/2009 at 04:44 EDT, Lee Stewart 
> >  wrote:
> >> I guess as the one who got bit, I'd offer one easy suggestion...
> >>
> >> The finger check asked for 9728G (9.7+T), VM 
> unceremoniously chopped 
> >> it to 8T as the architecture limit.  Why not have an option (not 
> >> enabled by
> >> default) in the SYSTEM CONFIG file that says Max_Virt_Size.   It 
> >> could take numbers (like the USER storage specification), 
> or OFF to 
> >> indicate no checking.   And maybe something like RSS for 
> Real Storage 
> >> Size to say you can't logon with or define storage to more 
> than the 
> >> amount of Real Storage.
> >>
> >> And if you really wanted a full circle, then a directory 
> option that 
> >> said this one user could override that setting.
> >>
> >> That said I'm kind of swamped for the next two weeks, but 
> after that 
> >> if someone wants to coach me on writing a requirement, I will...
> >
> > For DIRMAINT, look at the DVHXRA/B/C exits to implement 
> whatever kind 
> > of policy limits you like.
> >
> > Alan Altmark
> > z/VM Development
> > IBM Endicott
> >
> 

Re: VM lockup due to storage typo

[Ron Schmiedge]

I've been trying to follow the discussion and wondering if the
directory control statement

MAXSTORAGE

would have provided some protection from the finger check problem?



On Wed, Sep 16, 2009 at 2:59 PM, Alan Altmark  wrote:
> On Wednesday, 09/16/2009 at 04:44 EDT, Lee Stewart
>  wrote:
>> I guess as the one who got bit, I'd offer one easy suggestion...
>>
>> The finger check asked for 9728G (9.7+T), VM unceremoniously chopped it
>> to 8T as the architecture limit.  Why not have an option (not enabled by
>> default) in the SYSTEM CONFIG file that says Max_Virt_Size.   It could
>> take numbers (like the USER storage specification), or OFF to indicate
>> no checking.   And maybe something like RSS for Real Storage Size to say
>> you can't logon with or define storage to more than the amount of Real
>> Storage.
>>
>> And if you really wanted a full circle, then a directory option that
>> said this one user could override that setting.
>>
>> That said I'm kind of swamped for the next two weeks, but after that if
>> someone wants to coach me on writing a requirement, I will...
>
> For DIRMAINT, look at the DVHXRA/B/C exits to implement whatever kind of
> policy limits you like.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>

Re: VM lockup due to storage typo

[Alan Altmark]

On Wednesday, 09/16/2009 at 04:44 EDT, Lee Stewart 
 wrote:
> I guess as the one who got bit, I'd offer one easy suggestion...
> 
> The finger check asked for 9728G (9.7+T), VM unceremoniously chopped it
> to 8T as the architecture limit.  Why not have an option (not enabled by
> default) in the SYSTEM CONFIG file that says Max_Virt_Size.   It could
> take numbers (like the USER storage specification), or OFF to indicate
> no checking.   And maybe something like RSS for Real Storage Size to say
> you can't logon with or define storage to more than the amount of Real
> Storage.
> 
> And if you really wanted a full circle, then a directory option that
> said this one user could override that setting.
> 
> That said I'm kind of swamped for the next two weeks, but after that if
> someone wants to coach me on writing a requirement, I will...

For DIRMAINT, look at the DVHXRA/B/C exits to implement whatever kind of 
policy limits you like.

Alan Altmark
z/VM Development
IBM Endicott

Re: VM lockup due to storage typo

[Ethan Lanz]

On Wed, Sep 16, 2009 at 3:06 PM, Huegel, Thomas  wrote:

> I don't know that I want CP to do anything different than it does now
> EXCEPT I want z/VM to a) keep running and b) have some facility that I
> can use to be able to examine the system to find/fix the problem... I
>

I agree.  The mainframe has a long history of managing over committed
resources, but Linux is presenting new challenges since it was not written
to be virtualized.

Rob noted earlier:
> 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 seems to me that this will become a problem in other virtual environments
as well and, similar to the timer tick problem, another opportunity for the
mainframe to show Linux a better way to behave.

If Linux does not use up all available space when it starts, there is
opportunity to monitor and intervene before it gets critical. Then we do not
have to worry about making sure all our virtual blocks fit in the virtual
toy box.


> don't know/care how that get's done, maybe reserving some page space for
> CP and/or a special 'hook' into the HMC.. I'll leave that up to the
> developers.
>
> -Original Message-

> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
> Behalf Of P S
> Sent: Wednesday, September 16, 2009 12:53 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
>
> On Wed, Sep 16, 2009 at 10:42 AM, Schuh, Richard 
> wrote:
> > Logon would not be the right or only place to put it. DEF STOR is
> another possible place to err if the maximum storage was too high.
> Perhaps a check of virtual storage at IPL time. That is a common point
> that must be traversed no matter where the error occurred.
>
> Suggest this not get hung up on "But it won't be perfect" ideas. For
> DIRMAINT, perhaps a site configuration option could say "Warn me if a
> userid is defined with either storage limit above x". Similarly, at
> LOGON or DEFINE STORAGE, if the VMsize is > than the total page space
> defined, a warning would be useful.
>
> This doesn't help for aggregate overload (20x1GB with 4GB of page
> space), doesn't guarantee that XAUTOLOG BIGPIG won't spiral the system
> into the ground before the operator (what operator?) can react, etc.,
> but it would at least give some more informed consent.
>
> In this era of Big Numbers and big Linux guests, this is probably more
> important than it used to be -- in days of yore, if you accidentally
> defined a 32MB guest on an 8MB system, (a) there probably WAS enough
> page space, and (b) the user was probably CMS and wouldn't touch the
> pages that fast anyway.
>

Ethan

Re: VM lockup due to storage typo

[Lee Stewart]

I guess as the one who got bit, I'd offer one easy suggestion...

The finger check asked for 9728G (9.7+T), VM unceremoniously chopped it 
to 8T as the architecture limit.  Why not have an option (not enabled by 
default) in the SYSTEM CONFIG file that says Max_Virt_Size.   It could 
take numbers (like the USER storage specification), or OFF to indicate 
no checking.   And maybe something like RSS for Real Storage Size to say 
you can't logon with or define storage to more than the amount of Real 
Storage.


And if you really wanted a full circle, then a directory option that 
said this one user could override that setting.


That said I'm kind of swamped for the next two weeks, but after that if 
someone wants to coach me on writing a requirement, I will...


Lee

Alan Altmark wrote:

On Wednesday, 09/16/2009 at 09:14 EDT, RPN01  wrote:
I don't think, in this case, it is the user causing the problem at all. 

The
user didn't define their storage allocation, and in practice can't do 

that
at all. So the user didn't set up the situation which caused the 

integrity

issue, the system administrator did.


That was my point to Marcy: Not an integrity problem.  The system is 
obeying the sysadmin's instructions.



To my mind, if this requires addressing, it should be in the DIRECTXA
command, so as to help the system administrator in avoiding aiming the 

gun

at his toes.


DIRECTXA has no context in which to make such warnings.  Placing limits at 
LOGON would only apply to resource availability to hold the needed control 
structures.  When the guest begins to run and actually use all that 
memory, then another line of defense is needed.


Alan Altmark
z/VM Development
IBM Endicott




--

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

Re: OT: eclipse based info center

[Raymond Higgs]

The IBM z/VM Operating System  wrote on 
09/16/2009 04:31:55 PM:

> Rob van der Heij  
> Sent by: The IBM z/VM Operating System 
> 
> 09/16/2009 04:31 PM
> 
> Please respond to
> The IBM z/VM Operating System 
> 
> To
> 
> IBMVM@LISTSERV.UARK.EDU
> 
> cc
> 
> Subject
> 
> OT: eclipse based info center
> 
> Is it time already for another rant on "the new way to reading books" 
;-)
> 
> I had to look up stuff in one of the z/OS books and landed on the
> "z/OS V1R9 Information Center" - horrible experience, apart from the
> content. When you select something on the menu the contents is
> refreshed again and moves under the cursor, causing it to hover over a
> completely different section and pop up with stuff. And dog slow.
> Takes me 10 seconds to find the selected section has just a single
> sentence and no content at all. And I thought the option to "print
> topic and subtopics" would be useful... guess what, that's also full
> of links and navigation stuff. What are these people thinking?
> 
> But I've found the PDF - it downloads in less then a minute and after
> that I can browse it without taking a class on how to read IBM
> documentation.
> 
> Rob

Re: VM lockup due to storage typo

[David Boyes]

On 9/15/09 12:09 PM, "Daniel P. Martin"  wrote:

> *cough*SHARE requirement?*cough*

WAVV requirement WRIBDB04 submitted.

I suggested a SYSTEM CONFIG option and corresponding SET command to warn
user/operator and optionally halt IPL if a user requested LOGON or issued an
IPL command with a default VM size greater than the sum of real memory and
configured PAGE space. Normal setting would be MEMSANITY ON, but the SET
MEMSANITY OFF command would still allow experienced admins to shoot
themselves in the foot if necessary.

IBM: Since I seem to be Designated Requirements Dude these days, maybe you
should just give me direct login access to the requirements DB. It'd save
time, and you'd get requirements earlier in the planning cycle. 8-)

-- db

OT: eclipse based info center

[Rob van der Heij]

Is it time already for another rant on "the new way to reading books" ;-)

I had to look up stuff in one of the z/OS books and landed on the
"z/OS V1R9 Information Center" - horrible experience, apart from the
content. When you select something on the menu the contents is
refreshed again and moves under the cursor, causing it to hover over a
completely different section and pop up with stuff. And dog slow.
Takes me 10 seconds to find the selected section has just a single
sentence and no content at all. And I thought the option to "print
topic and subtopics" would be useful... guess what, that's also full
of links and navigation stuff. What are these people thinking?

But I've found the PDF - it downloads in less then a minute and after
that I can browse it without taking a class on how to read IBM
documentation.

Rob

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

[Victor Ochoa Avila]

Thanks Alan,  I am going to contact to our contact of IBM to ask for
information to the product.
Regards.


2009/9/16 Alan Altmark 

> On Wednesday, 09/16/2009 at 06:21 EDT, Victor Ochoa Avila
>  wrote:
>
> > Is correct Alan, I have a problem with ISPF/PDF, when run the command
> >
> > FLMSAVE
> >
> > I OBTAIN THIS ERROR
> >
> > 
>
> > ***  < AMPXLVEC TXTLIB > not found.
>
> > ***  This file is required to continue with the installation.
>
> > ***  Please verify that PASCAL has been previously installed
>
> > ***  and rerun the FLMSAVE exec.
>
> > 
>
> >
> > *** Save of ISPF/PDF SCLM aborted.
> >
> >
> > For this reason i ask for the Pascal files..
>
> Victor, ISPF/PDF SCLM is documented to have two pre-reqs
> VS Pascal Library (5668-717)
> VSE/VSAM for VM (book says 5746-AM2, but it was replaced by 5686-081)
>
> z/VM does NOT have 5668-717 pre-installed.  It has only the runtime needed
> by the IBM-provided TCP/IP clients and servers.  If you want the full
> runtime environment, you need to purchase it.
>
> Further, VSE/VSAM for VM is not available if you don't already have it,
> having been withdrawn in 2005. (Service was discontinued in 2007.)
>
> Bottom line: You can't install the SCLM component of ISPF/PDF unless (a)
> you buy the full Pascal RTL, and (b) you already have a license for VSAM.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>



-- 
Victor Hugo Ochoa Avila
z/OS & z/VM systems programmer
Mexico, City.

Re: VM lockup due to storage typo

[Huegel, Thomas]

I don't know that I want CP to do anything different than it does now
EXCEPT I want z/VM to a) keep running and b) have some facility that I
can use to be able to examine the system to find/fix the problem... I
don't know/care how that get's done, maybe reserving some page space for
CP and/or a special 'hook' into the HMC.. I'll leave that up to the
developers.   

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

On Wed, Sep 16, 2009 at 10:42 AM, Schuh, Richard 
wrote:
> Logon would not be the right or only place to put it. DEF STOR is
another possible place to err if the maximum storage was too high.
Perhaps a check of virtual storage at IPL time. That is a common point
that must be traversed no matter where the error occurred.

Suggest this not get hung up on "But it won't be perfect" ideas. For
DIRMAINT, perhaps a site configuration option could say "Warn me if a
userid is defined with either storage limit above x". Similarly, at
LOGON or DEFINE STORAGE, if the VMsize is > than the total page space
defined, a warning would be useful.

This doesn't help for aggregate overload (20x1GB with 4GB of page
space), doesn't guarantee that XAUTOLOG BIGPIG won't spiral the system
into the ground before the operator (what operator?) can react, etc.,
but it would at least give some more informed consent.

In this era of Big Numbers and big Linux guests, this is probably more
important than it used to be -- in days of yore, if you accidentally
defined a 32MB guest on an 8MB system, (a) there probably WAS enough
page space, and (b) the user was probably CMS and wouldn't touch the
pages that fast anyway.

Re: Linux and z/VM Wiki

[Peter . Webb]

One of the major problems for Wikipedia is that edits are anonymous, or
hide behind a pseudonym. It would provoke more trust if the person's
real name was available.


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  Any 
review retransmission dissemination or other use of or taking any action in 
reliance upon this information by persons or entities other than the intended 
recipient or delegate is strictly prohibited.  If you received this in error 
please contact the sender and delete the material from any computer.  The 
integrity and security of this message cannot be guaranteed on the Internet.  
The sender accepts no liability for the content of this e-mail or for the 
consequences of any actions taken on the basis of information provided.  The 
recipient should check this e-mail and any attachments for the presence of 
viruses.  The sender accepts no liability for any damage caused by any virus 
transmitted by this e-mail.  This disclaimer is property of the TTC and must 
not be altered or circumvented in any manner.

Re: Linux and z/VM Wiki

[Richard Troth]

You should require accounts.
Further, you should have them controlled by an admin or moderator.
Otherwise any script kiddie at a cafe in Bangladesh could clobber the content.






On 2009-09-16, Mark Post  wrote:
> Cross-posted to Linux-390, IBMVM, and IBM-Main
>
> The idea of having a Wiki (http://dictionary.reference.com/browse/wiki) for
> mainframe Linux and z/VM has been floating around for some time.  It was
> thought that having a Wiki with a fair amount of content already in it would
> help it reach a "critical mass" of usability far sooner than might otherwise
> happen.  A fair amount of behind-the-scenes work has been done over the last
> couple of years to make that happen, without much success.
>
> So, I've decided to take a different approach.  With the assistance of
> Marist College (and Velocity Software who owns the domain name), I've put up
> a Wiki at http://wiki.linuxvm.org/wiki/ for people to contribute content.
> We'll see how things go from here to determine if it's worth keeping or not.
>
> There are a few rules, for lack of a better term, that will apply to the
> Wiki, none of them particularly onerous:
>1.  Although technically not required, we would prefer that anyone
> contributing to the wiki create an account before doing so.
>2. Keep things civil and professional, both in the articles themselves,
> as well as the discussion pages for them.
>3. Keep things accurate. We expect vendor-specific information to be
> entered here (although we'd prefer to not have pricing details). But, any
> exaggerated claims, vapor ware announcements and the like are subject to
> summary deletion.
>4. Try to keep bias to a minimum. Everyone has their favorite
> distribution or way of doing things. Try not to let others people's
> preferences in those areas be cause for any Holy Wars [TM].
>5. If you don't own the copyright to something, don't add it to the wiki.
>6. Use common sense in general.
>
> I hope that people find this useful, and are willing to contribute as they
> are able.  With any luck, it will become a valuable resource for everyone
> that might become involved in running Linux on System z.
>
>
> Thanks,
>
> Mark Post
>

-- 
Sent from my mobile device

-- R;   <><

Re: VM lockup due to storage typo

[P S]

On Wed, Sep 16, 2009 at 10:42 AM, Schuh, Richard  wrote:
> Logon would not be the right or only place to put it. DEF STOR is another 
> possible place to err if the maximum storage was too high. Perhaps a check of 
> virtual storage at IPL time. That is a common point that must be traversed no 
> matter where the error occurred.

Suggest this not get hung up on "But it won't be perfect" ideas. For
DIRMAINT, perhaps a site configuration option could say "Warn me if a
userid is defined with either storage limit above x". Similarly, at
LOGON or DEFINE STORAGE, if the VMsize is > than the total page space
defined, a warning would be useful.

This doesn't help for aggregate overload (20x1GB with 4GB of page
space), doesn't guarantee that XAUTOLOG BIGPIG won't spiral the system
into the ground before the operator (what operator?) can react, etc.,
but it would at least give some more informed consent.

In this era of Big Numbers and big Linux guests, this is probably more
important than it used to be -- in days of yore, if you accidentally
defined a 32MB guest on an 8MB system, (a) there probably WAS enough
page space, and (b) the user was probably CMS and wouldn't touch the
pages that fast anyway.

Linux and z/VM Wiki

[Mark Post]

Cross-posted to Linux-390, IBMVM, and IBM-Main

The idea of having a Wiki (http://dictionary.reference.com/browse/wiki) for 
mainframe Linux and z/VM has been floating around for some time.  It was 
thought that having a Wiki with a fair amount of content already in it would 
help it reach a "critical mass" of usability far sooner than might otherwise 
happen.  A fair amount of behind-the-scenes work has been done over the last 
couple of years to make that happen, without much success.

So, I've decided to take a different approach.  With the assistance of Marist 
College (and Velocity Software who owns the domain name), I've put up a Wiki at 
http://wiki.linuxvm.org/wiki/ for people to contribute content.  We'll see how 
things go from here to determine if it's worth keeping or not.

There are a few rules, for lack of a better term, that will apply to the Wiki, 
none of them particularly onerous:
   1.  Although technically not required, we would prefer that anyone 
contributing to the wiki create an account before doing so.
   2. Keep things civil and professional, both in the articles themselves, as 
well as the discussion pages for them.
   3. Keep things accurate. We expect vendor-specific information to be entered 
here (although we'd prefer to not have pricing details). But, any exaggerated 
claims, vapor ware announcements and the like are subject to summary deletion.
   4. Try to keep bias to a minimum. Everyone has their favorite distribution 
or way of doing things. Try not to let others people's preferences in those 
areas be cause for any Holy Wars [TM].
   5. If you don't own the copyright to something, don't add it to the wiki.
   6. Use common sense in general.

I hope that people find this useful, and are willing to contribute as they are 
able.  With any luck, it will become a valuable resource for everyone that 
might become involved in running Linux on System z.


Thanks,

Mark Post

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

[Les Koehler]

Kris,
Your RxServer is more modern than my VMSERVE and has the 
advantage of your continual support, which I can't do w/o 
access to a VM system. Also, your technical knowledge has 
grown since I retired (and so has VM), so RxServe may have 
features that VMSERVE wasn't capable of.


VMSERVE is aimed at the Application Developer and my point 
in posting my PLUG was to raise awareness that many of the 
WAKEUP problems posted have already been solved with 
VMSERVE and the programmer can concentrate on his Business 
Application.


As old and tired as VMSERVE is, I notice that it still gets 
plenty of downloads, so at least some folks are exploring 
its usability.


I'm indebted to the original author (Rick Holt, at 
Yorktown) who transferred ownership to me back in the 80's 
and to the internal IBM community for their continuous 
feedback until I retired at the end of May, 2004.


Les

Kris Buelens wrote:


We had about 7 servers in each of up to 18 VM systems to manage, all based
on RxServer, and obviously we were able to do it all from one location.


2009/9/16 Les Koehler 


Iirc, Pipes provides the facilities to negate the problem, but I don't
remember the details.


Interested parties might want to investigate/try my VMSERVE PACKAGE from
the VM Download Library. It's a little old now, but when I retired it was
widely used within IBM, saving lots of folks a lot of effort in setting up
and running service machines.

My responsibilities in Global Services required me to monitor, at one time,
about 15 service machines across four systems connected via RSCS. All the
monitoring was automated and I was only notified of unexpected or missing
events.

I could even  schedule changes remotely, have them installed on the fly,
notify interested parties of their success or failure  and automatically
back them off if they failed to install.


Les

Chip Davis wrote:


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]

Logon would not be the right or only place to put it. DEF STOR is another 
possible place to err if the maximum storage was too high. Perhaps a check of 
virtual storage at IPL time. That is a common point that must be traversed no 
matter where the error occurred. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, September 16, 2009 10:20 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM lockup due to storage typo
> 
> On Wednesday, 09/16/2009 at 09:14 EDT, RPN01 
>  wrote:
> > I don't think, in this case, it is the user causing the 
> problem at all. 
> The
> > user didn't define their storage allocation, and in 
> practice can't do
> that
> > at all. So the user didn't set up the situation which caused the
> integrity
> > issue, the system administrator did.
> 
> That was my point to Marcy: Not an integrity problem.  The 
> system is obeying the sysadmin's instructions.
> 
> > To my mind, if this requires addressing, it should be in 
> the DIRECTXA 
> > command, so as to help the system administrator in avoiding 
> aiming the
> gun
> > at his toes.
> 
> DIRECTXA has no context in which to make such warnings.  
> Placing limits at LOGON would only apply to resource 
> availability to hold the needed control structures.  When the 
> guest begins to run and actually use all that memory, then 
> another line of defense is needed.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: OT: VM lockup due to English typo

[Shimon Lebowitz]

I see in your email that the URL was wrapped, and the 
final "L" was moved to a different line.
Try this (I snipped off the obvious "http://"; part):
itre.cis.upenn.edu/~myl/languagelog/archives/001035.html

 Original message 
>Date:   Wed, 16 Sep 2009 07:56:42 -0400
>From:   Les Koehler   
>Subject:   Re: OT: VM lockup due to English typo  
>To:   IBMVM@LISTSERV.UARK.EDU
>
>Not Found
>
>Les
>
>Shimon Lebowitz wrote:
>>  Original message 
>>> 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).
>> 
>> 
>> 
http://itre.cis.upenn.edu/~myl/languagelog/archives/001035.htm
>> l
>> 
>> 

Re: VM lockup due to storage typo

[Alan Altmark]

On Wednesday, 09/16/2009 at 09:14 EDT, RPN01  wrote:
> I don't think, in this case, it is the user causing the problem at all. 
The
> user didn't define their storage allocation, and in practice can't do 
that
> at all. So the user didn't set up the situation which caused the 
integrity
> issue, the system administrator did.

That was my point to Marcy: Not an integrity problem.  The system is 
obeying the sysadmin's instructions.

> To my mind, if this requires addressing, it should be in the DIRECTXA
> command, so as to help the system administrator in avoiding aiming the 
gun
> at his toes.

DIRECTXA has no context in which to make such warnings.  Placing limits at 
LOGON would only apply to resource availability to hold the needed control 
structures.  When the guest begins to run and actually use all that 
memory, then another line of defense is needed.

Alan Altmark
z/VM Development
IBM Endicott

Re: VM lockup due to storage typo

[Tom Duerbusch]

If you bought the Dirmaint product or a simular product from another vender, 
couldn't a rule be setup to prevent this?

Anyway, there is not gonna be a way of preventing a systems programmer from 
doing anything we do.  We are suppose to be thinking.

For example, when I initialize, format or copy to a pack, I go thru, at least 3 
checks to make sure I have not transpose the CUA.  Saved me a lot of times.

A system programmer IS dangerous.  We can shutdown the system.  We can destroy 
the system (and then go peacefully in retirement).

You can't fix stupid and we are all, occassionaly, stupid.

Now you had this kind of problem, we all should learn from it.  After defining 
a new guest, log on to that guest and do a Q V ALL and see if it is right.

Been there, done that.

Tom Duerbusch
THD Consulting

Sent via BlackBerry by AT&T

-Original Message-
From: RPN01 

Date: Wed, 16 Sep 2009 08:13:57 
To: 
Subject: Re: VM lockup due to storage typo


I don't think, in this case, it is the user causing the problem at all. The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set up the situation which caused the integrity
issue, the system administrator did.

The system administrator is in control of the CP Directory, and as such,
decisions are left to him. The system doesn't question what he does, within
the definition of the syntax, semantics and limitations of the directory
entries and commands. If you want to define a large virtual machine, should
the system question your authority?

The system could check the memory and page space against each directory
entry as the binary directory is built, but this would add time to the
directory build, and does not account for the situation of planning to add
more page space before logging in the new directory entry. Maybe a warning
of "User  exceeds paging space" could have averted this situation, but
again, each user would have to be checked against the running system. It
shouldn't keep you from creating the entry, just let you know that there
might be an issue if you actually use it.

To my mind, if this requires addressing, it should be in the DIRECTXA
command, so as to help the system administrator in avoiding aiming the gun
at his toes.

-- 
Robert P. Nix  Mayo Foundation.~.
RO-OE-5-55 200 First Street SW/V\
507-284-0844   Rochester, MN 55905   /( )\
-^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 9/15/09 3:44 PM, "Alan Altmark"  wrote:

> 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: PPRC commands under z/VM

[Alan Altmark]

On Tuesday, 09/15/2009 at 10:53 EDT, Florian Bilek 
 wrote:

> 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. 

z/VM does not have CP commands to manage PPRC connections.  You will need 
to do it via ICKDSF.

Alan Altmark
z/VM Development
IBM Endicott

Re: ERROR ESTABLISHING COMMUNICATIONS

[Alan Altmark]

On Wednesday, 09/16/2009 at 09:53 EDT, Shimon Lebowitz  
wrote:
> >
> > CRR is only required to be active when one wants to update files in 
two
> > different filepools in the same LUW, often thus in the same exec. I 
don't
> > know if you have applications requiring that, if not, you can restart
> > VMSERVR.
> 
> I also thought like that, but if that is the case,
> then why would the lack of CRR prevent ANY access to the pool???
> 
> q enroll user for all ypool:
> DMSQRE2008E ERROR ESTABLISHING COMMUNICATIONS BETWEEN CRR RECOVERY 
SERVER
> DMSQRE2008E AND FILE POOL YPOOL. ERROR CODES -3 AND 11. DETECTING MODULE 
DMS3LA
> READY(00104); T=0.01/0.01 16:50:03

The error indicates a failure in the Exchange Log Names.  Did you perhaps 
change the LUNAME parameter in the DMSPARMS file?

Alan Altmark
z/VM Development
IBM Endicott

Re: Adding TDISK

[Schuh, Richard]

The command is probably DRAIN rather than STOP, is it not? START reverses the 
DRAIN.


Regards,
Richard Schuh






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

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 mailto:rsc...@visa.com>>
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:IBMVM@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:IBMVM@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.





--
Kris Buelens,
IBM Belgium, VM customer support

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

[Alan Altmark]

On Wednesday, 09/16/2009 at 06:21 EDT, Victor Ochoa Avila 
 wrote:

> Is correct Alan, I have a problem with ISPF/PDF, when run the command
> 
> FLMSAVE
> 
> I OBTAIN THIS ERROR
> 
>  
  
> ***  < AMPXLVEC TXTLIB > not found. 
   
> ***  This file is required to continue with the installation.   
   
> ***  Please verify that PASCAL has been previously installed 
  
> ***  and rerun the FLMSAVE exec. 
  
>  
   
>   
> *** Save of ISPF/PDF SCLM aborted. 
> 
> 
> For this reason i ask for the Pascal files..

Victor, ISPF/PDF SCLM is documented to have two pre-reqs
VS Pascal Library (5668-717) 
VSE/VSAM for VM (book says 5746-AM2, but it was replaced by 5686-081)

z/VM does NOT have 5668-717 pre-installed.  It has only the runtime needed 
by the IBM-provided TCP/IP clients and servers.  If you want the full 
runtime environment, you need to purchase it.

Further, VSE/VSAM for VM is not available if you don't already have it, 
having been withdrawn in 2005. (Service was discontinued in 2007.)

Bottom line: You can't install the SCLM component of ISPF/PDF unless (a) 
you buy the full Pascal RTL, and (b) you already have a license for VSAM.

Alan Altmark
z/VM Development
IBM Endicott

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

[Kris Buelens]

We had about 7 servers in each of up to 18 VM systems to manage, all based
on RxServer, and obviously we were able to do it all from one location.


2009/9/16 Les Koehler 

> Iirc, Pipes provides the facilities to negate the problem, but I don't
> remember the details.
>
> 
> Interested parties might want to investigate/try my VMSERVE PACKAGE from
> the VM Download Library. It's a little old now, but when I retired it was
> widely used within IBM, saving lots of folks a lot of effort in setting up
> and running service machines.
>
> My responsibilities in Global Services required me to monitor, at one time,
> about 15 service machines across four systems connected via RSCS. All the
> monitoring was automated and I was only notified of unexpected or missing
> events.
>
> I could even  schedule changes remotely, have them installed on the fly,
> notify interested parties of their success or failure  and automatically
> back them off if they failed to install.
> 
>
> Les
>
> Chip Davis wrote:
>
>> 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.
>>>
>>
>>
>>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: ERROR ESTABLISHING COMMUNICATIONS

[Kris Buelens]

In my experience, an SFS server can live without CRR.  We only had problems
with a CRR down when an EXEC tried to open files in two filepools; the
second open in Write-mode was refused.
Your problem seems different in that you acnnot even access that singel pool
anymore...

2009/9/16 Shimon Lebowitz 

> >
> > CRR is only required to be active when one wants to update files in two
> > different filepools in the same LUW, often thus in the same exec. I don't
> > know if you have applications requiring that, if not, you can restart
> > VMSERVR.
>
> I also thought like that, but if that is the case,
> then why would the lack of CRR prevent ANY access to the pool???
>
>  q enroll user for all ypool:
> DMSQRE2008E ERROR ESTABLISHING COMMUNICATIONS BETWEEN CRR RECOVERY SERVER
> DMSQRE2008E AND FILE POOL YPOOL. ERROR CODES -3 AND 11. DETECTING MODULE
> DMS3LA
> READY(00104); T=0.01/0.01 16:50:03
>
>  dirl ypool:77731619.
> DMSJLD653E ERROR EXECUTING LISTDIR, RC=104
> READY(00104); T=0.01/0.01 16:50:06
>
>  ac ypool:77731619. w
> DMSACR2008E ERROR ESTABLISHING COMMUNICATIONS BETWEEN CRR RECOVERY SERVER
> DMSACR2008E AND FILE POOL YPOOL. ERROR CODES -3 AND 11. DETECTING MODULE
> DMS3LA
> READY(00104); T=0.01/0.01 16:50:18
>
> That is why I really do not want to touch anything that just MIGHT
> break!!
>
> My entire production system is at risk here, and tomorrow is the last
> work day before a major holiday.
>
> > There are also some CRR operator commands -that I don't know by
> > heart- that you might want to execute, maybe some query followed by some
> > ERASE-like command.  They are contained in the SFS manual.
> >
>
> --
> 
> Shimon Lebowitzmailto:shim...@iname.com
> VM System Programmer   .
> Israel Police National HQ.
> Jerusalem, Israel  phone: +972 2 542-9877  fax: 542-9308
> 
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: VM lockup due to storage typo

[Rob van der Heij]

This gun has been pointing in the same direction forever, but it *is*
a fact that with 64-bit CP the bullets are a lot bigger.

I am sure folks in Edicott are as creative as most of us (or worse,
take a look at ... ;-)  but we know that any safety that CP adds will
annoy people because they forgot to disable it when they still had the
option to do so, or because they drive with the safety off all day
anyway (how many are not using highly privileged CP userid for things
that don't need it - and really, it *is* dangerous)

The problem with the suggested check is that it is stronger than what
most people need. Also, the check is likely to be unfair (aiming at
the wrong victim) and potentially cause a Denial of Service. Would you
want MAINT unable to logon because that 5th Linux guest now logged on
(and you could only add the page pack if you could logon...)  So we
need an option for some users to override it, or an option to enforce
the check only for some users. One means that you may forget the
option, and the other means that within weeks people will ask "why
can't I logon my Linux guest" and the word will spread that you need
to issue a SET SRM OVERCOMM .

Linux has a similar check in that a process can't allocate more
virtual memory than you have available (in main and on swap, or you
get out-of-memory). This ensures that this process could eventually
get all it asks for. But when it does not immediately reference that
memory, it appears to be still available when the next process
allocates memory. So the check is pretty useless and does not protect
you at all.

I don't do operational work these days, so feel on the peanut gallery.
Maybe I grew up in a rather unique shop (or maybe staff reductions
have gotten rid of that luxury there too) but we had pretty strict
rules to minimize mistakes. Most configuration changes would be
checked by another pair of eyes or some code. Configuration files to
be replaced ran through XDIFF to inspect the changes. The nucleus map
was scanned for text decks picked up from the A-disk, etc. Various
health checks ran to compare RACF and the directory, check for certain
disks filling up, and many more. With CMS Pipelines it is often easy
to get an extra pair of eyes oversee your actions.

Rob

Re: VM lockup due to storage typo

[Brian Nielsen]

And you also have to check during DEFINE STORAGE, DEFINE FB-512, and any 

other command or function that creates a pagable CP structure.

Brian Nielsen

On Wed, 16 Sep 2009 09:03:43 -0500, Mike Walter  

wrote:

>I can't support DIRECTXA as the sole examination.  Paging volumes can be

>added at any time.  DIRECTXA only gets a change to look when it is run.
>
>If this even needs to be addressed (hence, this thoughtful thread), IMHO

>comparing the min and max virtual machine memory specification would be
>better done when the virtual machine is being built during
>logon/autolog/xautolog.
>
>OTOH, it would not hurt to have DIRECTXA provide that early warning so
>that when one finally does attempt to create the virtual machine, any
>typos might already have been displayed and corrected when DIRECTXA
>provided an early warning.  It's just plain embarrassing for an existing

>virtual machine to cause a problem because the sysprog made a wild (or
>uninformed) keystroke while editing the directory source ... another
>source of sysprog "collateral damage".
>
>Mike Walter
>Hewitt Associates
>The opinions expressed herein are mine alone, not my employer's.
>
>
>
>RPN01 
>
>Sent by: "The IBM z/VM Operating System" 
>09/16/2009 08:13 AM
>Please respond to
>"The IBM z/VM Operating System" 
>
>
>
>To
>IBMVM@LISTSERV.UARK.EDU
>cc
>
>Subject
>Re: VM lockup due to storage typo
>
>
>
>
>
>
>I don't think, in this case, it is the user causing the problem at all.
>The
>user didn't define their storage allocation, and in practice can't do th
at
>at all. So the user didn't set up the situation which caused the integri
ty
>issue, the system administrator did.
>
>The system administrator is in control of the CP Directory, and as such,

>decisions are left to him. The system doesn't question what he does,
>within
>the definition of the syntax, semantics and limitations of the directory

>entries and commands. If you want to define a large virtual machine,
>should
>the system question your authority?
>
>The system could check the memory and page space against each directory
>entry as the binary directory is built, but this would add time to the
>directory build, and does not account for the situation of planning to a
dd
>more page space before logging in the new directory entry. Maybe a warni
ng
>of "User  exceeds paging space" could have averted this situation, b
ut
>again, each user would have to be checked against the running system. It

>shouldn't keep you from creating the entry, just let you know that there

>might be an issue if you actually use it.
>
>To my mind, if this requires addressing, it should be in the DIRECTXA
>command, so as to help the system administrator in avoiding aiming the g
un
>at his toes.
>
>--
>Robert P. Nix  Mayo Foundation.~.
>RO-OE-5-55 200 First Street SW/V\
>507-284-0844   Rochester, MN 55905   /( )\
>-^^-^^
>"In theory, theory and practice are the same, but
> in practice, theory and practice are different."
>
>
>
>
>On 9/15/09 3:44 PM, "Alan Altmark"  wrote:
>
>> 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 forethough
t
>> hang or abend CP, it WILL be classified as an integrity problem (denia
l
>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 integri
ty
>> 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
>
>
>
>
>
>
>The information contained in this e-mail and any accompanying documents 

may contain information that is confidential or otherwise protected from 

disclosure. If you are not the intended recipient of this message, or if 

this message has been addressed to you in error, please immediately alert
 
the sender by reply e-mail and then delete this message, including any 

attachments. Any dissemination, distribution or other use of the contents
 
of this message by anyone ot

Re: OT: VM lockup due to English typo

[Brian Nielsen]

The OP's line wrapped in the middle of the URL.

Brian Nielsen

On Wed, 16 Sep 2009 07:56:42 -0400, Les Koehler  

wrote:

>Not Found
>
>Les
>
>Shimon Lebowitz wrote:
>>  Original message 
>>> 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).
>>
>>
>> http://itre.cis.upenn.edu/~myl/languagelog/archives/001035.htm
>> l
>>
>>
>
=

Re: VM lockup due to storage typo

[Mike Walter]

I can't support DIRECTXA as the sole examination.  Paging volumes can be 
added at any time.  DIRECTXA only gets a change to look when it is run. 

If this even needs to be addressed (hence, this thoughtful thread), IMHO 
comparing the min and max virtual machine memory specification would be 
better done when the virtual machine is being built during 
logon/autolog/xautolog. 

OTOH, it would not hurt to have DIRECTXA provide that early warning so 
that when one finally does attempt to create the virtual machine, any 
typos might already have been displayed and corrected when DIRECTXA 
provided an early warning.  It's just plain embarrassing for an existing 
virtual machine to cause a problem because the sysprog made a wild (or 
uninformed) keystroke while editing the directory source ... another 
source of sysprog "collateral damage".

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



RPN01  

Sent by: "The IBM z/VM Operating System" 
09/16/2009 08:13 AM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: VM lockup due to storage typo






I don't think, in this case, it is the user causing the problem at all. 
The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set up the situation which caused the integrity
issue, the system administrator did.

The system administrator is in control of the CP Directory, and as such,
decisions are left to him. The system doesn't question what he does, 
within
the definition of the syntax, semantics and limitations of the directory
entries and commands. If you want to define a large virtual machine, 
should
the system question your authority?

The system could check the memory and page space against each directory
entry as the binary directory is built, but this would add time to the
directory build, and does not account for the situation of planning to add
more page space before logging in the new directory entry. Maybe a warning
of "User  exceeds paging space" could have averted this situation, but
again, each user would have to be checked against the running system. It
shouldn't keep you from creating the entry, just let you know that there
might be an issue if you actually use it.

To my mind, if this requires addressing, it should be in the DIRECTXA
command, so as to help the system administrator in avoiding aiming the gun
at his toes.

-- 
Robert P. Nix  Mayo Foundation.~.
RO-OE-5-55 200 First Street SW/V\
507-284-0844   Rochester, MN 55905   /( )\
-^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 9/15/09 3:44 PM, "Alan Altmark"  wrote:

> 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






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

Re: ERROR ESTABLISHING COMMUNICATIONS

[Shimon Lebowitz]

> 
> CRR is only required to be active when one wants to update files in two
> different filepools in the same LUW, often thus in the same exec. I don't
> know if you have applications requiring that, if not, you can restart
> VMSERVR.  

I also thought like that, but if that is the case, 
then why would the lack of CRR prevent ANY access to the pool???

 q enroll user for all ypool:
DMSQRE2008E ERROR ESTABLISHING COMMUNICATIONS BETWEEN CRR RECOVERY SERVER
DMSQRE2008E AND FILE POOL YPOOL. ERROR CODES -3 AND 11. DETECTING MODULE DMS3LA
READY(00104); T=0.01/0.01 16:50:03

 dirl ypool:77731619.
DMSJLD653E ERROR EXECUTING LISTDIR, RC=104
READY(00104); T=0.01/0.01 16:50:06

 ac ypool:77731619. w
DMSACR2008E ERROR ESTABLISHING COMMUNICATIONS BETWEEN CRR RECOVERY SERVER
DMSACR2008E AND FILE POOL YPOOL. ERROR CODES -3 AND 11. DETECTING MODULE DMS3LA
READY(00104); T=0.01/0.01 16:50:18

That is why I really do not want to touch anything that just MIGHT 
break!!

My entire production system is at risk here, and tomorrow is the last 
work day before a major holiday.

> There are also some CRR operator commands -that I don't know by
> heart- that you might want to execute, maybe some query followed by some
> ERASE-like command.  They are contained in the SFS manual.
> 

-- 

Shimon Lebowitzmailto:shim...@iname.com
VM System Programmer   .
Israel Police National HQ. 
Jerusalem, Israel  phone: +972 2 542-9877  fax: 542-9308

Re: VM lockup due to storage typo

[RPN01]

I don't think, in this case, it is the user causing the problem at all. The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set up the situation which caused the integrity
issue, the system administrator did.

The system administrator is in control of the CP Directory, and as such,
decisions are left to him. The system doesn't question what he does, within
the definition of the syntax, semantics and limitations of the directory
entries and commands. If you want to define a large virtual machine, should
the system question your authority?

The system could check the memory and page space against each directory
entry as the binary directory is built, but this would add time to the
directory build, and does not account for the situation of planning to add
more page space before logging in the new directory entry. Maybe a warning
of "User  exceeds paging space" could have averted this situation, but
again, each user would have to be checked against the running system. It
shouldn't keep you from creating the entry, just let you know that there
might be an issue if you actually use it.

To my mind, if this requires addressing, it should be in the DIRECTXA
command, so as to help the system administrator in avoiding aiming the gun
at his toes.

-- 
Robert P. Nix  Mayo Foundation.~.
RO-OE-5-55 200 First Street SW/V\
507-284-0844   Rochester, MN 55905   /( )\
-^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 9/15/09 3:44 PM, "Alan Altmark"  wrote:

> 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: ERROR ESTABLISHING COMMUNICATIONS

[Kris Buelens]

CRR is only required to be active when one wants to update files in two
different filepools in the same LUW, often thus in the same exec.
I don't know if you have applications requiring that, if not, you can
restart VMSERVR.  There are also some CRR operator commands -that I don't
know by heart- that you might want to execute, maybe some query followed by
some ERASE-like command.  They are contained in the SFS manual.

2009/9/16 Shimon Lebowitz 

> >
> > Did you also restart VMSERVR?
> >
>
> Nope. I have half a dozen other production fileservers
> running with this CRR server. I do not want to do ANYTHING
> to upset the apple-cart, and possibly, heaven forbid!!, leave
> me with another server dead like YPOOL (which is not
> really production).
>
> Does Q RESOURCE reveal names for VMSERVR?
>
> Yes, Here is what I get:
>
>  pipe cp Q RESOURCE|Locate /VMSERVR/|cons
> RESOURCE: VMSYSRTYPE: LOCAL   OWNING USERID: VMSERVR
> SERVICE:  30F0F2F9  TYPE: LOCAL   OWNING USERID: VMSERVR
> SERVICE:  06F2  TYPE: SYSTEM  OWNING USERID: VMSERVR
> SERVICE:  30F0F2F7  TYPE: LOCAL   OWNING USERID: VMSERVR
> READY; T=0.01/0.01 13:07:09
>
>
> >
> > Did someone change the IUCV permissions of YPOOL and/or VMSERVR in the CP
> > directory?
>
> No.
>  YPOOLVMRMAINT A0  V 80  TRUNC=71 SIZE=55 LINE=16
> >
>
> * * * TOP OF FILE * * *
> USER YPOOL   64M96M G
>   13  LINE(S) NOT DISPLAYED -
>  IUCV ALLOW
>  IUCV *IDENT RESANY GLOBAL
>   39  LINE(S) NOT DISPLAYED -
>
>  VMSERVR  VMRMAINT A0  V 80  TRUNC=71 SIZE=40 LINE=13
> >
>
> * * * TOP OF FILE * * *
> USER VMSERVR   32M32M BG
>   10  LINE(S) NOT DISPLAYED -
>  IUCV ALLOW
>  IUCV *IDENT RESANY GLOBAL
>   27  LINE(S) NOT DISPLAYED -
> * * * END OF FILE * * *
>
> >
> > No console messages?
>
> Nothing at all on either console.
>
>
> > Nor error files on VMSERVR 191/YPOOL 191?
>
> None.
>
> Thank you!
> Shimon
>
> --
> 
> Shimon Lebowitzmailto:shim...@iname.com
> VM System Programmer   .
> Israel Police National HQ.
> Jerusalem, Israel  phone: +972 2 542-9877  fax: 542-9308
> 
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: OT: VM lockup due to English typo

[Les Koehler]

Not Found

Les

Shimon Lebowitz wrote:

 Original message 
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).



http://itre.cis.upenn.edu/~myl/languagelog/archives/001035.htm
l

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

[Les Koehler]

Iirc, Pipes provides the facilities to negate the problem, 
but I don't remember the details.



Interested parties might want to investigate/try my VMSERVE 
PACKAGE from the VM Download Library. It's a little old 
now, but when I retired it was widely used within IBM, 
saving lots of folks a lot of effort in setting up and 
running service machines.


My responsibilities in Global Services required me to 
monitor, at one time, about 15 service machines across four 
systems connected via RSCS. All the monitoring was 
automated and I was only notified of unexpected or missing 
events.


I could even  schedule changes remotely, have them 
installed on the fly, notify interested parties of their 
success or failure  and automatically back them off if they 
failed to install.



Les

Chip Davis wrote:
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.

OT: VM lockup due to English typo

[Shimon Lebowitz]

 Original message 
>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).


http://itre.cis.upenn.edu/~myl/languagelog/archives/001035.htm
l

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

[Victor Ochoa Avila]

Hi Alan

Is correct Alan, I have a problem with ISPF/PDF, when run the command
FLMSAVE

I OBTAIN THIS ERROR


***  < AMPXLVEC TXTLIB > not found.
***  This file is required to continue with the installation.
***  Please verify that PASCAL has been previously installed
***  and rerun the FLMSAVE exec.


*** Save of ISPF/PDF SCLM aborted.


For this reason i ask for the Pascal files..


Best Regards.








Yep I have a TCPASCAL TXTLIB   Q2  on TCPMAINT 592 dis


2009/9/15 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
>



-- 
Victor Hugo Ochoa Avila
z/OS & z/VM systems programmer
Mexico, City.

Re: ERROR ESTABLISHING COMMUNICATIONS

[Shimon Lebowitz]

> 
> Did you also restart VMSERVR?  
>

Nope. I have half a dozen other production fileservers 
running with this CRR server. I do not want to do ANYTHING
to upset the apple-cart, and possibly, heaven forbid!!, leave 
me with another server dead like YPOOL (which is not 
really production).

Does Q RESOURCE reveal names for VMSERVR?

Yes, Here is what I get:

 pipe cp Q RESOURCE|Locate /VMSERVR/|cons
RESOURCE: VMSYSRTYPE: LOCAL   OWNING USERID: VMSERVR
SERVICE:  30F0F2F9  TYPE: LOCAL   OWNING USERID: VMSERVR
SERVICE:  06F2  TYPE: SYSTEM  OWNING USERID: VMSERVR
SERVICE:  30F0F2F7  TYPE: LOCAL   OWNING USERID: VMSERVR
READY; T=0.01/0.01 13:07:09


> 
> Did someone change the IUCV permissions of YPOOL and/or VMSERVR in the CP
> directory?

No. 
 YPOOLVMRMAINT A0  V 80  TRUNC=71 SIZE=55 LINE=16
>

* * * TOP OF FILE * * *  
USER YPOOL   64M96M G   
  13  LINE(S) NOT DISPLAYED -
 IUCV ALLOW  
 IUCV *IDENT RESANY GLOBAL   
  39  LINE(S) NOT DISPLAYED -

 VMSERVR  VMRMAINT A0  V 80  TRUNC=71 SIZE=40 LINE=13
>

* * * TOP OF FILE * * *  
USER VMSERVR   32M32M BG  
  10  LINE(S) NOT DISPLAYED -
 IUCV ALLOW  
 IUCV *IDENT RESANY GLOBAL   
  27  LINE(S) NOT DISPLAYED -
* * * END OF FILE * * *  

> 
> No console messages?  

Nothing at all on either console.


> Nor error files on VMSERVR 191/YPOOL 191?

None.

Thank you!
Shimon

-- 

Shimon Lebowitzmailto:shim...@iname.com
VM System Programmer   .
Israel Police National HQ. 
Jerusalem, Israel  phone: +972 2 542-9877  fax: 542-9308

Re: How much memory?

[Vince Getgood]

Guys,
Thanks for all your help.
Unfortunately management (at MD level) have shot this idea down.

Sometimes, I wonder if there is any commitment at all for the mainframe 

platform