Re: Quick question

[Brian Westerman]

Sorry in advance for the marketing plug,

There is the older free AUTO product on the CBT and I think there is another
scheduler that actually uses JES2 to do the work.  Then there is SyzAUTO/z,
which is not free but is both quite inexpensive and 100% supported.  It
allows job submission based on any timeofday, dayofweek/month/year, and has
facilities to provide the highest condition codes via EMAIL and several
other key features.

The older free version has some issues with some times of day that are all
resolved on SyzAUTO/z. 

Besides already being inexpensive, there are discounts for members of
IBM-Main and SHARE on all of our system management and automation products.

end of marketing plug.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[DanD]

There are vendor products out there to do this.

ThruPut Manager's JTS; CA must have something after they took over 
Cybermation.

Any scheduling package has time related submission.

If you're looking for something free, is there nothing on the CBT site?

Dan

-Original Message- 
From: John McKown
Sent: Sunday, July 03, 2011 8:38 AM Newsgroups: bit.listserv.ibm-main 
Subject: Re: Quick question


I've never been in a JES3 shop. Only VS1/JES1, MVT/HASP, an MVS/JES2.

On Sun, 2011-07-03 at 04:05 -0400, Shmuel Metz (Seymour J.) wrote:

In <1309442922.9025.14.ca...@dv7t.johnmckown.net>, on 06/30/2011
   at 09:08 AM, John McKown  said:

>I can't think of anything off hand.

Isn't there a basic scheduling facility in JES3 DJC?


--
John McKown
Maranatha! <>< 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[John McKown]

I've never been in a JES3 shop. Only VS1/JES1, MVT/HASP, an MVS/JES2.

On Sun, 2011-07-03 at 04:05 -0400, Shmuel Metz (Seymour J.) wrote:
> In <1309442922.9025.14.ca...@dv7t.johnmckown.net>, on 06/30/2011
>at 09:08 AM, John McKown  said:
> 
> >I can't think of anything off hand.
> 
> Isn't there a basic scheduling facility in JES3 DJC?
>  

-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[Shmuel Metz (Seymour J.)]

In <1309442922.9025.14.ca...@dv7t.johnmckown.net>, on 06/30/2011
   at 09:08 AM, John McKown  said:

>I can't think of anything off hand.

Isn't there a basic scheduling facility in JES3 DJC?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[Alvaro Guirao Lopez]

The most useful answer in my particular case is David's answer, but I see
some RACF problems, I'll solve them.
I want to do this from another system in a batch job, so I don't want to
quiesce or submit with TYPRUN=HOLD.

Thanks a lot for your comments.
Kind regards,
Álvaro.



2011/6/30 Larry Macioce 

> How about typrun=hold on the jobcard then release when ready?
>
> mace
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Un saludo.
Álvaro Guirao

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[Larry Macioce]

How about typrun=hold on the jobcard then release when ready?

mace

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[John McKown]

I can't think of anything off hand. Do you want to delay the job before
it is running in an initiator or while it is still in the input queue
before it hits the initiator?

You could issue the operator command:

reset jobname,quiesce

to force the running job to stop until you do:

reset jobname,resume

On Thu, 2011-06-30 at 15:44 +0200, Alvaro Guirao Lopez wrote:
> Hello friends,
> 
> There is any program for delay a job execution in the serverpac of z/OS
> V1R11?
> 
> Thanks in advance.
> 

-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick question

[David Andrews]

On Thu, 2011-06-30 at 09:44 -0400, Alvaro Guirao Lopez wrote:
> There is any program for delay a job execution in the serverpac of z/OS
> V1R11?

Perhaps you're looking for something like this?

//DELAY   EXEC PGM=BPXBATCH,PARM='pgm /bin/sleep &SECONDS'

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Quick question

[Alvaro Guirao Lopez]

Hello friends,

There is any program for delay a job execution in the serverpac of z/OS
V1R11?

Thanks in advance.

-- 
Un saludo.
Álvaro Guirao

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Knutson, Sam]

To follow-up on the case here when a DB2 DBA accidently overcommitted
storage to DB2 an APAR PK58272 is now open against DB2 to provide a WTO
message that can be automated to notify and escalate if a DBA does this
and gets the message DSNB542I.

PK58272 MAKE DSNB542I A WTO MESSAGE, SO THAT THE CHECKING OF THIS
MESSAGE CAN BE AUTOMATED.

Here a DBA transposed some numbers in a job and got DSNB542I but did not
immediately back out the changes. 

DSNB542I  -DB2P DSNB1ABP THE TOTAL ACTIVE PGFIX YES BUFFER POOL
STORAGE
   EXCEEDS THE DB2 ALLOWED REAL STORAGE CAPACITY
   WHEN EXPANDING STORAGE FOR BUFFER POOL BP24
   CURRENT VPSIZE = 40
   NEW VPSIZE = 200
   REAL STORAGE CAPACITY = 73728 MB.
DSN9022I  -DB2P DSNB1CMD '-ALT BPOOL' NORMAL COMPLETION

Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 
 
"Think big, act bold, start simple, grow fast..."


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick Question - how to get XCFAS to release CTC device to allow CHPID to go offline

[Diehl, Gary (MVSSupport)]

All,

Thank you for your responses.  I know I've done these commands before,
but I surely was drawing a blank today.

I got the intermittently failing CHPID offline without any problems,
thanks to your excellent advice.  Thanks again!

Best regards,

Gary Diehl
MVS Support
"The glass is neither half full or half empty; the engineer who designed
the glass simply allowed for a 100% increase in fluid storage."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick Question - how to get XCFAS to release CTC device to allow CHPID to go offline

[Jihad K Kawkabani]

SETXCF STOP,PI,DEV()
SETXCF STOP,PO,DEV()

Regards,

Jihad K. Kawkabani
IT Systems Engineer Consultant
Voice: 440.395.0740
Network: 575.0740
Cell: 440.465.2969



   
 "Diehl, Gary  
 (MVSSupport)" 
 <[EMAIL PROTECTED]  To 
 ATE.COM>  IBM-MAIN@BAMA.UA.EDU
 Sent by: IBM   cc 
 Mainframe 
 Discussion List   Subject 
 <[EMAIL PROTECTED] Quick Question - how to get XCFAS   
 .EDU> to release CTC device to allow  
   CHPID to go offline 
 11/20/2007 10:51  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
       




All,

Quick question (which I RTFM'd but didn't find an answer to):

How do I get XCFAS to release a set of CTC UCBs that it has allocated
(as shown by D U,,ALLOC,,y) so that I can take the CHPID offline?

VTAM has let go of it, with the inactivation of the TRLs, but XCFAS is
using the other devices that VTAM wasn't and I can't seem to find a
command that tells him to gracefully let go.

There are other, redundant CTC connections that will take over when
these drop, so it's not a single point of failure.  I need the CHPID
offline so we can get the hardware under it looked at (might be
intermittently failing).

I'd hate to just pull the CHPID out from under it, I do value my
system's stability!

Thanks and best regards,

Gary Diehl
MVS Support
"The glass is neither half full or half empty; the engineer who designed
the glass simply allowed for a 100% increase in fluid storage."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Quick Question - how to get XCFAS to release CTC device to allow CHPID to go offline

[Mark Jacobs]

Diehl, Gary (MVSSupport) wrote:
> All,
> 
> Quick question (which I RTFM'd but didn't find an answer to):
> 
> How do I get XCFAS to release a set of CTC UCBs that it has allocated
> (as shown by D U,,ALLOC,,y) so that I can take the CHPID offline?
> 
> VTAM has let go of it, with the inactivation of the TRLs, but XCFAS is
> using the other devices that VTAM wasn't and I can't seem to find a
> command that tells him to gracefully let go.
> 
> There are other, redundant CTC connections that will take over when
> these drop, so it's not a single point of failure.  I need the CHPID
> offline so we can get the hardware under it looked at (might be
> intermittently failing).
> 
> I'd hate to just pull the CHPID out from under it, I do value my
> system's stability!
> 
> Thanks and best regards,
> 
> Gary Diehl
> MVS Support
> "The glass is neither half full or half empty; the engineer who designed
> the glass simply allowed for a 100% increase in fluid storage."
> 
>

Stop the pathin/pathout for those addresses using the SETXCF STOP command.
-- 
Mark Jacobs
Time Customer Service
Tampa, FL
--

The primary purpose of the DATA statement is to give names to
constants; instead of referring to pi as 3.141592653589793 at
every appearance, the variable PI can be given that value with
a DATA statement and used instead of the longer form of the constant.

This also simplifies modifying the program, should the value of
pi change.

- FORTRAN manual for Xerox computers

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Quick Question - how to get XCFAS to release CTC device to allow CHPID to go offline

[Diehl, Gary (MVSSupport)]

All,

Quick question (which I RTFM'd but didn't find an answer to):

How do I get XCFAS to release a set of CTC UCBs that it has allocated
(as shown by D U,,ALLOC,,y) so that I can take the CHPID offline?

VTAM has let go of it, with the inactivation of the TRLs, but XCFAS is
using the other devices that VTAM wasn't and I can't seem to find a
command that tells him to gracefully let go.

There are other, redundant CTC connections that will take over when
these drop, so it's not a single point of failure.  I need the CHPID
offline so we can get the hardware under it looked at (might be
intermittently failing).

I'd hate to just pull the CHPID out from under it, I do value my
system's stability!

Thanks and best regards,

Gary Diehl
MVS Support
"The glass is neither half full or half empty; the engineer who designed
the glass simply allowed for a 100% increase in fluid storage."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Staller, Allan]

I have never encountered a "bad" page dataset. I have encountered page
errors within a page dataset (usually due to some sort of IO error).

The last time I encountered this (circa 1985) the task referencing the
"bad page" received a S028 abend. The system marked the slot in the page
dataset as "bad" and proceeded on it's merry way.



As for pagedel - if the page data set hits an error, I think ASM marks
it bad, writes an abend089 dump and then either a number of address
spaces will fail (those with pages out there on that data set) or only
one slot is bad, and then the rest of the system goes on. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Barbara Nitz]

What I really don't understand in the pageadd/pagedel discussion:

Once a large sdump is taken (provided maxspace is big enough) and the system 
hits the aux storage shortage threshold (first one at 70%), sdump stops 
capturing. The dump will be incomplete, but the system is not in any danger of 
wait stating 03C. 

Has this changed?

Once a page data set is added, leave it there until the next IPL and after. 
Chances are you'll need it again.

As for pagedel - if the page data set hits an error, I think ASM marks it bad, 
writes an abend089 dump and then either a number of address spaces will fail 
(those with pages out there on that data set) or only one slot is bad, and then 
the rest of the system goes on. 

Regards, Barbara Nitz
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Ted MacNEIL]

>A question on PAGEDEL: What happens if a page data set goes bad and you don't 
>delete it?

Since at least MVS/SP 1.1, the ASM and MVS recovery handles that.

There should be never a reason to PAGEDEL.
It doesn't hurt to be over-allocated on aux store, these days.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Martin Packer]

A question on PAGEDEL: What happens if a page data set goes bad and you 
don't delete it?

It's just I vaguely recall a long time ago there being a problem under 
such circumstances. VERY vaguely recall by the way. But that might be a 
reason to be able to do a PAGEDEL.

Martin (who's never done a PAGEDEL nor PAGEADD neither) :-)

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Roland Schiradin]

Shane, 

right. It wasn't me who introduce the PAGEDEL command.
In the past we had several reserved page datasets which was used/shared by 
several LPARs. Automation add's and delete them on demand. This was fine for 
several years unless this add/delete happen more frequently because of some 
DB2 dumps after DB2 V8 comes real. 

I wasn't aware of this "bad" effect until we fall into this. Well just an IPL. 
Also I don't see the PAGEDEL command is dangerous in some cases.
Perhaps I miss some docs or it still isn't documented. 

However we hit this and perhaps we aren't the only one. 
Best would be to document this behaviour for the PAGEDEL command. 

Roland


>On Fri, 2007-11-09 at 21:35 +0100, Roland wrote:
>
>> Also AFAIR the PAGEDEL didn't release all storage so massive
>> combination of PAGEADD/PAGEDEL can cause problems too.
>
>PAGEDEL ???. That's what IPLs are for.
>I'm with Mark - you add a page dataset, you leave it there.
>
>Get any current problems sorted, then worry about the preferred
>configuration later.
>There may be reasons for removing page datasets (rarely), but certainly
>not in the heat of battle.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Ed Gould]

On Nov 9, 2007, at 6:53 PM, Eric Bielefeld wrote:

Yeah - and the best thing about buying more memory is IBM doesn't  
raise the price of the software like they do if you buy a faster  
processor!



Eric:

Ss!!! you might give them ideas .

Ed



Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434

- Original Message - From: "Knutson, Sam" <[EMAIL PROTECTED]>


Memory is cheap relative to other System z resources you can buy.
   Best Regards,

   Sam Knutson, GEICO
   System z Performance and Availability Management
   mailto:[EMAIL PROTECTED]
   (office)  301.986.3574


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Eric Bielefeld]

Yeah - and the best thing about buying more memory is IBM doesn't raise the 
price of the software like they do if you buy a faster processor!


Eric Bielefeld
Sr. z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434

- Original Message - 
From: "Knutson, Sam" <[EMAIL PROTECTED]>


Memory is cheap relative to other System z resources you can buy.
   Best Regards,

   Sam Knutson, GEICO
   System z Performance and Availability Management
   mailto:[EMAIL PROTECTED]
   (office)  301.986.3574 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Shane]

On Fri, 2007-11-09 at 21:35 +0100, Roland wrote:

> Also AFAIR the PAGEDEL didn't release all storage so massive
> combination of PAGEADD/PAGEDEL can cause problems too.

PAGEDEL ???. That's what IPLs are for.
I'm with Mark - you add a page dataset, you leave it there.

Get any current problems sorted, then worry about the preferred
configuration later.
There may be reasons for removing page datasets (rarely), but certainly
not in the heat of battle.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Schiradin,Roland HG-Dir itb-db/dc]

Hmmmh IBM-DB2 l2 often refuse to even at partial dumps

Also AFAIR the PAGEDEL didn't release all storage so massive
combination of PAGEADD/PAGEDEL can cause problems too. We had
this problem because of automation, sick

Roland 



-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Friday, November 09, 2007 8:52 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question


On Fri, 9 Nov 2007 19:32:51 +, Martin Packer 
<[EMAIL PROTECTED]>
wrote:
>
>You'd better be able to contain the dump space requirements.

MAXSPACE= on your dump options.

>Worst case in
>paging space. Better case in memory, though that might not be 
>economically feasible. I've known 3 separate cases of customers either 
>running out of paging space or getting awfully close. And no, I don't 
>know the syntax for PAGEADD or whatever it's called. Do you in 
a hurry? 
>:-)
>

Yes, but maybe I can't type that fast or probably I am not looking at
the console.  :-)   That is what automation is for.

But using automation to add pagespace after a aux shortage message begs
the question:   If you are already putting the DASD aside for 
the spare page 
data set(s), why not just add it to begin with?   Perhaps in 
the "old days" you 
kept a spare on the back end of some volume where response time 
mattered.  
But now, unless you have SLED DASD that wouldn't be an issue (unless 
you had it on the back of a volume that you let get RESERVEd).  With 
customizable volume sizes... or even if you don't use custom sizes (DR 
considerations), DASD is still cheap enough to define all your 
spares up 
front and always have them available for the worst case scenario.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Mark Zelden]

On Fri, 9 Nov 2007 19:32:51 +, Martin Packer <[EMAIL PROTECTED]>
wrote:
>
>You'd better be able to contain the dump space requirements. 

MAXSPACE= on your dump options.

>Worst case in
>paging space. Better case in memory, though that might not be economically
>feasible. I've known 3 separate cases of customers either running out of
>paging space or getting awfully close. And no, I don't know the syntax for
>PAGEADD or whatever it's called. Do you in a hurry? :-)
>

Yes, but maybe I can't type that fast or probably I am not looking at
the console.  :-)   That is what automation is for.

But using automation to add pagespace after a aux shortage message begs
the question:   If you are already putting the DASD aside for the spare page 
data set(s), why not just add it to begin with?   Perhaps in the "old days" you 
kept a spare on the back end of some volume where response time mattered.  
But now, unless you have SLED DASD that wouldn't be an issue (unless 
you had it on the back of a volume that you let get RESERVEd).  With 
customizable volume sizes... or even if you don't use custom sizes (DR 
considerations), DASD is still cheap enough to define all your spares up 
front and always have them available for the worst case scenario.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Martin Packer]

John Reda wrote:

Using large quantities of storage can, in the right situation
dramatically improve performance.  But (there's always a But...) you
need to be VERY careful, make sure that the storage you are going to use
is not only available right now but that it will be available for the
duration of your job.  You also need the ability to back off when the
system gets busy for an unexpected reason.  The consequences of over
committing storage can be catastrophic.  If there is a system outage
related to storage and you are holding a big chunk, it will be your
fault.  It doesn't matter what else happened, it's your fault and this
time it is not just one person or group, it effects everyone running on
the system. 


A classic example is when a large address space - eg DB2's DBM1  (not to 
pick on it but it can be MASSIVE) - dumps...

You'd better be able to contain the dump space requirements. Worst case in 
paging space. Better case in memory, though that might not be economically 
feasible. I've known 3 separate cases of customers either running out of 
paging space or getting awfully close. And no, I don't know the syntax for 
PAGEADD or whatever it's called. Do you in a hurry? :-)

Martin

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Reda, John]

Using large quantities of storage can, in the right situation
dramatically improve performance.  But (there's always a But...) you
need to be VERY careful, make sure that the storage you are going to use
is not only available right now but that it will be available for the
duration of your job.  You also need the ability to back off when the
system gets busy for an unexpected reason.  The consequences of over
committing storage can be catastrophic.  If there is a system outage
related to storage and you are holding a big chunk, it will be your
fault.  It doesn't matter what else happened, it's your fault and this
time it is not just one person or group, it effects everyone running on
the system.

Picture those old movies where there is a line of people.  They are
asked a question and the guilty party is supposed to step forward.
Everyone but one person takes a step back leaving just one person.  That
person is left with a bewildered look on his face and is instantly
guilty.   

John Reda
Syncsort, Inc.
201-930-8260

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Knutson, Sam
Sent: Friday, November 09, 2007 1:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question



SyncSort or DFSORT will both exploit more memory to improve performance
easily.  Some adjustments may help things run the way you want.  Both
SyncSort and IBM provide good advice as well as good software.



Best Regards, 
Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

DO SOMETHING!) SMALL) USEFUL) NOW!) - computer pioneer  Bob Bemer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Knutson, Sam]

Tom Beretvas used to have a saying the answer to all DASD performance
problems was "More Cache!".  Now he said that tongue in cheek and then
illustrated that there was some truth in it and of course it was not
always the answer.

So in the same vein if you want to say "More Memory!" is the answer to
all performance problems I will agree:-)  I like memory.  It is the
cheapest thing I can buy to improve performance.  It is of course part
of a balanced solution but the millions of dollars people will spend on
processors and then try to save a few gigabytes of memory and allow
those precious processors to spend cycles doing paging or allow
applications to incur delays due to wait for I/O that is easily avoided
boggles me.

Memory is cheap relative to other System z resources you can buy.
Today's 2094 is not your old 4381 just faster.  When you can combine
current IBM operating system z/OS, current subsystems DB2, MQ, IMS, and
current balanced hardware solutions z9 and DS8300 the sum is greater
than any of the parts with very few weak spots.  Plenty of memory on the
host processor is an enabler for a lot of z/OS and DB2 exploitation.
Don't put DB2 or z/OS on a memory starvation diet and then complain it
is not up to peak performance demands. 

Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574

"Think big, act bold, start simple, grow fast..." 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Moulder
Sent: Friday, November 09, 2007 1:42 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Memory solves all problems.

Tom Moulder quoting Ted VanDuyn

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Tom Moulder]

Memory solves all problems.

Tom Moulder quoting Ted VanDuyn

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Knutson, Sam
Sent: Friday, November 09, 2007 12:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Hi,

 

You are going to do a great service to the business if you can make the
case to use a valued asset you already own to improve service.  Go for
it! 

 

You can absolutely leverage the better part of 2 gigabytes of memory
just for DB2 buffer pools in V7.  Pay attention to peak storage demands
in DB2xDBM1 address space and remember that in V7 you can do some tricks
like data spaces you lose in V8.  Get more detailed advice on the DB2-L
list.

 

I think the level of concern may be to high here. 10G really is not that
much even on z/OS 1.7 we had LPARs several times that size without any
problem. There are some IEAOPTxx parms that can minimize RSM overhead on
1.7 that have been documented by IBM now but we found that made a
difference on really large LPAR's 40G - 80G not 10G LPARs.

 

Remember "There is NO I/O like NO I/O"!  

 

You can exploit extra real memory with products you already have in hand
easily. 

 

SyncSort or DFSORT will both exploit more memory to improve performance
easily.  Some adjustments may help things run the way you want.  Both
SyncSort and IBM provide good advice as well as good software.

 

Exploit VLF! Increase your cache size for CSVLLA and look at other
exploitation of LLA/VLF.

 

The best paging is no paging.  Paging on z/OS is a waste of cycles put
enough storage on you don't normally page.

 

DB2! One of DB2's best defenses against I/O is sufficiently large buffer
pools intelligently allocated with DB2 objects and thresholds.

DB2 V7 is OK.  DB2 V8 is much better at exploiting LOTS of storage.

 

Spare storage?  Are you planning on adding an LPAR?  If not setup your
HSA with plenty of room for dynamic growth and use the rest.  At $8K/G
or $10/G it seems wasteful to leave it idle.

 

 

Best Regards, 

 

Sam Knutson, GEICO 

System z Performance and Availability Management 

mailto:[EMAIL PROTECTED] 

(office)  301.986.3574 

 

DO SOMETHING!) SMALL) USEFUL) NOW!) - computer pioneer  Bob Bemer

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 5:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Real storage usage - a quick question

 

Esteemed listers

 

I've a problem but I haven't any answer to it or better I've different 

answers. 

 

Say we have a machine with, just to say, 10 Gb of real storage. Only 5
are 

used by the only LPAR defined (actually there's  another very small
LPAR, 

but it's real small), which is a WLC LPAR and often it's CPU capped.  5
Gb 

remain unused. I asked why, as I'd like to enlarge my bufferpools in DB2


(for instance).  I've got these answers:

 

- Increasing real storage increases cpu overhead to managed more memory 

blocks in a cpu-constrained machine. 

- Increasing real storage causes more workload so more chanches to hit
WLC 

capping. 

- It's better to have some spare storage (5 Gb ?). 

 

Our workload is increasing and we have some occasional paging spikes.
DB2 

doesn't perform well due to too small pools. 

 

According listers' experience, is using the most part/all real  storage 

(perhaps with a spare memory for future incrases) a real problem ? Did 

anyone experimented any problem ? What are guidelines ? 

 

Thank you in advance

 

Max Scarpa

 

 


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-- 
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM


No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.26/1120 - Release Date: 11/9/2007
9:26 AM
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email

Re: Real storage usage - a quick question

[Knutson, Sam]

Hi,

 

You are going to do a great service to the business if you can make the
case to use a valued asset you already own to improve service.  Go for
it! 

 

You can absolutely leverage the better part of 2 gigabytes of memory
just for DB2 buffer pools in V7.  Pay attention to peak storage demands
in DB2xDBM1 address space and remember that in V7 you can do some tricks
like data spaces you lose in V8.  Get more detailed advice on the DB2-L
list.

 

I think the level of concern may be to high here. 10G really is not that
much even on z/OS 1.7 we had LPARs several times that size without any
problem. There are some IEAOPTxx parms that can minimize RSM overhead on
1.7 that have been documented by IBM now but we found that made a
difference on really large LPAR's 40G - 80G not 10G LPARs.

 

Remember "There is NO I/O like NO I/O"!  

 

You can exploit extra real memory with products you already have in hand
easily. 

 

SyncSort or DFSORT will both exploit more memory to improve performance
easily.  Some adjustments may help things run the way you want.  Both
SyncSort and IBM provide good advice as well as good software.

 

Exploit VLF! Increase your cache size for CSVLLA and look at other
exploitation of LLA/VLF.

 

The best paging is no paging.  Paging on z/OS is a waste of cycles put
enough storage on you don't normally page.

 

DB2! One of DB2's best defenses against I/O is sufficiently large buffer
pools intelligently allocated with DB2 objects and thresholds.

DB2 V7 is OK.  DB2 V8 is much better at exploiting LOTS of storage.

 

Spare storage?  Are you planning on adding an LPAR?  If not setup your
HSA with plenty of room for dynamic growth and use the rest.  At $8K/G
or $10/G it seems wasteful to leave it idle.

 

 

Best Regards, 

 

Sam Knutson, GEICO 

System z Performance and Availability Management 

mailto:[EMAIL PROTECTED] 

(office)  301.986.3574 

 

DO SOMETHING!) SMALL) USEFUL) NOW!) - computer pioneer  Bob Bemer

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 5:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Real storage usage - a quick question

 

Esteemed listers

 

I've a problem but I haven't any answer to it or better I've different 

answers. 

 

Say we have a machine with, just to say, 10 Gb of real storage. Only 5
are 

used by the only LPAR defined (actually there's  another very small
LPAR, 

but it's real small), which is a WLC LPAR and often it's CPU capped.  5
Gb 

remain unused. I asked why, as I'd like to enlarge my bufferpools in DB2


(for instance).  I've got these answers:

 

- Increasing real storage increases cpu overhead to managed more memory 

blocks in a cpu-constrained machine. 

- Increasing real storage causes more workload so more chanches to hit
WLC 

capping. 

- It's better to have some spare storage (5 Gb ?). 

 

Our workload is increasing and we have some occasional paging spikes.
DB2 

doesn't perform well due to too small pools. 

 

According listers' experience, is using the most part/all real  storage 

(perhaps with a spare memory for future incrases) a real problem ? Did 

anyone experimented any problem ? What are guidelines ? 

 

Thank you in advance

 

Max Scarpa

 

 


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Knutson, Sam]

Using more memory in DB2 V8 running on z/OS 1.7 can still be a net
positive.

 

There are some things you can set in IEAOPTxx to reduce overhead.

 

z/OS 1.8 is the real solution for handling large memory more efficiently
in z/OS but the benefits of large buffer pools with DB2 V8 are pretty
significant.  

 

 

/*   */

/*  SRM INVOCATION INTERVAL CONSTANT */

/* SET TO 3K PER LOCAL FIX FOR OA18452 TILL CLOSURE... SJK MAR-08-07 */

/* WAS 1K*/

  RMPTTOM=3000,

/*   */

/* UICFRAMESCHECKTIME is the number of frames (in thousands) that*/

/* RSM processes on one address space queue before checking for the  */

/* RSM timeout value which is internally defaulted at 25ms. While*/

/* the system is running address space queues to do UIC updating the */

/* RSM lock is held. Other callers who need this lock (such as to do */

/* a page fix to do DB2 I/O, or assigning a frame) will spin waiting */

/* for the address space queue to be processed. The default  */

/* UICFRAMESCHECKTIME is 525 (2GB).  */

/*   */

/* Set to 5 per IBM WSC ...SJK JUL-18-07 */

  UICFRAMESCHECKTIME=5   

 

The support for UICFRAMESCHECKTIME was provided with APAR OA07055 which
can be reviewed for additional information.  

 

YMMV so do your own research and testing and consider consulting IBM if
you think you really have a problem this may help.  I wouldn't suggest
you go making changes to IEAOPTxx to add either RMPTTOM or
UICFRAMESCHECKTIME if you are happy with your current z/OS 1.7 system.


 

Best Regards, 

 

Sam Knutson, GEICO 

System z Performance and Availability Management 

mailto:[EMAIL PROTECTED] 

(office)  301.986.3574 

 

"Think big, act bold, start simple, grow fast..." 

 

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Veilleux, Jon L
Sent: Wednesday, November 07, 2007 9:49 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

 

In z/OS 1.8 the memory management is much more conducive to large

memory. They no longer use the least recently used algorithm and no

longer check every page. This has made a big difference for us. Under

1.7 we had issues with large real memory sizes due to the constant

checking by RSM. This is no longer the case and we have increased our

memory dramatically with no performance hit.

 

 

 

Jon L. Veilleux

[EMAIL PROTECTED]

(860) 636-2683 


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Mark Zelden]

On Thu, 8 Nov 2007 09:02:05 +0100, Max Scarpa <[EMAIL PROTECTED]>
wrote:

>Jumping from 4  to 25 Gb isn't a good idea, but if I have 4 Gb used and 4
>unused I think there's no difference in adding, say, 2 Gb (so using 6 Gb
>as total). Consider we have bursts or spikes in paging and for instance
>our DB2 isn't performing well even if 'all runs well' as someone say.
>

If you are paging at all, then add all 4 Gb.

>Anyway is there any rule of thumb, having z/OS 1.7, for max central
>storage ? I mean, is there a suggested value to avoid RSM overhead before
>z/OS 1.8 (1 Gb ? 5, 10 or which value for central storage) ?
>

I don't think there is an ROT, just the warning that if you aren't paging
at all, don't add gobs of storage "just because".A few GB isn't going to
be noticeable or measurable.   No need to micro-manage.   It also isn't
going to matter unless you are running at or near 100% busy and
you want to squeeze every last cycle out of the machine that you 
can.  I say this because a lot of shops do run that way.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.

[EMAIL PROTECTED] (Knutson, Sam) writes:
> You should have the PTFs for z/OS APAR OA17114 installed if you are
> using paged fixed buffers in DB2 V8.   Not having it was one of the
> causes of a z/OS outage here when a DB2 DBA accidently overcommitted
> storage to DB2.

aka application page fixed buffers ... allows applications to specify
the "real addresses" in the channel program ... avoiding the dynamic
channel program translation (creating a duplicate of the channel program
passed by excp/svc0) and dynamic page fixing that otherwise has to occur
on every i/o operations (however, it can eliminate pageable storage
needed by the rest of system)

recent post mentioning difference between EXCP and EXCPVR (vis-a-vis
channel program translation)
http://www.garlic.com/~lynn/2007q.html#8 GETMAIN/FREEMAIN and virtual storage 
backing up

other recent posts discussing dynamic channel program translation (in
the initial translation from MVT to OS/VS2 supporting virtual memory,
there was extensive borrowing of technology from cp67 CCWTRANS, channel
program translation)
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question
http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007n.html#35 IBM obsoleting mainframe hardware
http://www.garlic.com/~lynn/2007o.html#37 Each CPU usage
http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation
http://www.garlic.com/~lynn/2007p.html#69 GETMAIN/FREEMAIN and virtual storage 
backing up
http://www.garlic.com/~lynn/2007p.html#70 GETMAIN/FREEMAIN and virtual storage 
backing up
http://www.garlic.com/~lynn/2007p.html#72 A question for the Wheelers - 
Diagnose instruction
http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Knutson, Sam]

You should have the PTFs for z/OS APAR OA17114 installed if you are
using paged fixed buffers in DB2 V8.   Not having it was one of the
causes of a z/OS outage here when a DB2 DBA accidently overcommitted
storage to DB2.

APAR Identifier .. OA17114  Last Changed  07/07/03
  IRA400E 04,PAGEABLE STORAGE SHORTAGE  HIGH VIRTUAL STORAGE
  FIXED IN "ABOVE" FRAMES INSTEAD OF "HIGH" FRAMES
 
  Symptom .. MS MSGIRA400EStatus ... CLOSED  PER
  Severity ... 2  Date Closed . 07/05/31
  Component .. 5752SC1CR  Duplicate of 
  Reported Release . 720  Fixed Release  999
  Component Name 5752 REAL STOR   Special Notice   HIPER
  Current Target Date ..07/06/15  Flags  RESTART/BOOT/IPL
  SCP ...
  Platform 
 
  Status Detail: SHIPMENT - Packaged solution is available for
shipment.
 
  PE PTF List:
 
  PTF List:
  Release 709   : UA34631 available 07/06/13 (F706 )
  Release 720   : UA34632 available 07/06/13 (F706 )
  Release 730   : UA34633 available 07/06/13 (F706 )
  Release 740   : UA34634 available 07/06/13 (F706 )


You should also need to educate your DBA's that they must confirm all
increases in DB2 bufferpool storage.  If they get any error they should
immediately back out whatever they did.

A DBA transposed some numbers in job and got DSNB542I but did not
immediately back out the changes. 

DSNB542I  -DB2P DSNB1ABP THE TOTAL ACTIVE PGFIX YES BUFFER POOL
STORAGE
   EXCEEDS THE DB2 ALLOWED REAL STORAGE CAPACITY
   WHEN EXPANDING STORAGE FOR BUFFER POOL BP24
   CURRENT VPSIZE = 40
   NEW VPSIZE = 200
   REAL STORAGE CAPACITY = 73728 MB.
DSN9022I  -DB2P DSNB1CMD '-ALT BPOOL' NORMAL COMPLETION


It would be useful if DB2 allowed an installation to set the percentage
to decline to allow buffer pools increases beyond rather than hard
coding 80%.

DSNB542I csect-name THE TOTAL ACTIVE PGFIX YES BUFFER POOL STORAGE
EXCEEDS
THE DB2 ALLOWED REAL STORAGE CAPACITY WHEN EXPANDING STORAGE FOR

BUFFER POOL bpname CURRENT VPSIZE = cbpsize NEW VPSIZE =

nbpsize REAL STORAGE CAPACITY = rsc MB.

 

 Explanation:  When expanding the VPSIZE for an active PGFIX YES buffer

 pool, DB2 detects that the total storage allocated for all active PGFIX

 YES buffer pools will exceed 80% of the real storage capacity on this
z/OS
 image. The ALTER BUFFERPOOL command fails and the buffer pool will

 continue to be active with the current VPSIZE value.

 

 The buffer pool attributes and real storage capacity are:

 

 bpnameThe buffer pool name.

 

 cbpsize   The current VPSIZE for the buffer pool.

 

 nbpsize   The new VPSIZE that was specified on the ALTER BUFFERPOOL

   command.

 

 rsc   The real storage capacity of this z/OS image in units of

   megabytes (1 MB = 2**20 bytes).

 System Action:  The ALTER BUFFERPOOL command fails. The buffer pool

 continues to be active with the current VPSIZE.

 

 System Programmer Response:  Either allocate more real storage to this

 z/OS image, reduce the requested size of the buffer pool or use the
PGFIX 
 NO attribute.


Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 
 
"Think big, act bold, start simple, grow fast..."

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Roland Schiradin
Sent: Wednesday, November 07, 2007 1:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Hi Max, 

if you're going to V8 make sure the bufferpools are "pagefixed"
otherwise
DB2 have to do it for each I/O.  


Roland

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Max Scarpa]

Jumping from 4  to 25 Gb isn't a good idea, but if I have 4 Gb used and 4 
unused I think there's no difference in adding, say, 2 Gb (so using 6 Gb 
as total). Consider we have bursts or spikes in paging and for instance 
our DB2 isn't performing well even if 'all runs well' as someone say. 

Anyway is there any rule of thumb, having z/OS 1.7, for max central 
storage ? I mean, is there a suggested value to avoid RSM overhead before 
z/OS 1.8 (1 Gb ? 5, 10 or which value for central storage) ? 

Thank you in advance

Max Scarpa





 




Mark Zelden <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
07/11/2007 17.30
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Real storage usage - a quick question






On Wed, 7 Nov 2007 10:22:30 -0500, Veilleux, Jon L <[EMAIL PROTECTED]> 
wrote:

>In 1.7 RSM took more CPU when we increased our real storage since it had
>to look at every frame for the UIC. It's a simple equation, more frames
>more CPU to scan them for their UIC. Our performance area noticed that
>there was an increase. I believe that it showed up as uncaptured CPU or
>MVS usage under OMEGAMON CPU utilization.
>

Exactly.  So if you are running below z/OS 1.8 and aren't paging, don't
just add 25G of storage because you have it laying around doing nothing
since you upgraded your processor and added all the "cheap" memory. 

We've discussed this before.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at 
http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Roland Schiradin]

Hi Max, 

if you're going to V8 make sure the bufferpools are "pagefixed" otherwise
DB2 have to do it for each I/O.  


Roland

>Hi Martin how is it ?
>
>We're in V7, I suppose you warned about 2 Gb limit. If the case, I can
>assure you we're quite far from 2GB limit...
>
>Anyway you've said that there were highly variable results (in tests and
>in late 80s) which means that sometime things went better and sometimes
>things worsened (about cpu usage I presume). Is it correct ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Mark Zelden]

On Wed, 7 Nov 2007 10:22:30 -0500, Veilleux, Jon L <[EMAIL PROTECTED]> wrote:

>In 1.7 RSM took more CPU when we increased our real storage since it had
>to look at every frame for the UIC. It's a simple equation, more frames
>more CPU to scan them for their UIC. Our performance area noticed that
>there was an increase. I believe that it showed up as uncaptured CPU or
>MVS usage under OMEGAMON CPU utilization.
>

Exactly.  So if you are running below z/OS 1.8 and aren't paging, don't
just add 25G of storage because you have it laying around doing nothing
since you upgraded your processor and added all the "cheap" memory.  

We've discussed this before.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


[EMAIL PROTECTED] (Veilleux, Jon L) writes:
> In z/OS 1.8 the memory management is much more conducive to large
> memory. They no longer use the least recently used algorithm and no
> longer check every page. This has made a big difference for us. Under
> 1.7 we had issues with large real memory sizes due to the constant
> checking by RSM. This is no longer the case and we have increased our
> memory dramatically with no performance hit.

one of the things found in "clock" LRU-approximation that i had
originally done as undergraduate in the 60s
http://www.garlic.com/~lynn/subtopic.html#wsclock

was that if the interval between page resets started to exceed some
limit, then there was little differention benefit of the reset activity
... least recently used tends to have some implicit dependencies on
amount of "history" ... if the duration is too long ... then it lost
much of its correlation being able to differentate between pages as to
future page reference pattern.

however across a wide range of configurations and workloads in the 70s,
"clock" LRU-approximation had the advantage of effectively being able to
(usefully) dynamically adapt the interval. however with a lot of cp67
experimenting and also heavy use of storage reference traces and page
replacement modeling ... it was possible to show that outside some
useful operating range ... the use of LRU algorithms for
differentiating/predicting future page reference behavior became less
and less accurate. It was also possible to show that for very large
memories ... that the overhead of repeatedly resetting page reference
bits provided less benefit than any possible improvement in page
replacement strategy.

we did do some experimenting at the science center attempting to
recognize the operating region/environment across where clock
LRU-approximated was beneficial ... and attempt to take some secondary
measures/strategies when it was outside that operating
region/envrionment.

one of the scenarios was that most LRU-approximation algorithms are
measured against how well they performed vis-a-vis simulation that
exactly implemented least-recently-used page ordering (measured in terms
of total page faults for given workload and real storage size).  "Good"
approximations tended to come within 5-15 percent (total page faults) of
"real" least-recently-used page ordering. We were able to find some page
replacement variations that instead of being 5-15 percent worse/more
(total page faults compared to simulated "real" least-recently-used page
ordering), we were able to show 5-15 percent fewer total page faults.

the scenario was that in some configuration/workload scenarios,
LRU-approximate could effectively cycle thru every page in real storage
w/o finding a candidate ... and then take the first page it started
with. Besides having a lot of processing overhead, this characteristic
effectively degraded to FIFO page replacement (there are operating
regions for LRU where it can degenerate to FIFO page replacement at the
same time taking an extrodinary amount of processor overhead). our
variation tended to recognize when operating in this
configuration/workload region and effectively switched to RANDOM page
replacement at very low processor overhead (and modeling showed that
when not able to make any other differentiation between pages to be
replaced ... RANDOM replacement makes better choice than FIFO,
independent of the overhead issue).

In fact, the original cp67 delivered at the univ. last week jan68,
... also referenced here
http://www.garlic.com/~lynn/2007r.html#74 System 360 EBCDIC vs. ASCII

... effectively implemented something that tended to operate as FIFO
replacement with purely software and didn't make use of the hardware
reference bits. As undergraduate, I did the kernel algorithm and
software changes to implement "clock" LRU-approximation page replacement
... taking advantage of page replacement bits. In this scenario ...
with only on the order of 120 real "pageable pages" ... this reduced the
time spent in page replacement selection (under relatively heavy load)
from approx. 10 percent of total processor to effectively unmeasureable
(and at the same time drastically improvement the quality of the
replacement choice).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Veilleux, Jon L]

I don't have specific numbers, but it was noticable. 


Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Wednesday, November 07, 2007 10:51 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

>In 1.7 RSM took more CPU when we increased our real storage since it 
>had to look at every frame for the UIC. It's a simple equation

And, the increas was?

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Martin Packer]

Max, that's right. I used to call that book the "DIM Coffee Table" book. 
:-) It was a nice illustration of the benefit of Data In Memory (DIM). I 
wish I recalled the form number.

But definitely I recall one of the "take home" messages being "DIM might 
well benefit you but it's highly variable whether it will save you or cost 
you CPU". VIO to Expanded Storage is one exploiter I remember being 
graphed as negative under some conditions and positive under others.

(Slightly) later on I'd co-write the Storage Configuration Guidelines 
Redbooks. But that's another story. :-)

Cheers, Martin

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Ted MacNEIL]

>In 1.7 RSM took more CPU when we increased our real storage since it had to 
>look at every frame for the UIC. It's a simple equation

And, the increas was?

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Veilleux, Jon L]

In 1.7 RSM took more CPU when we increased our real storage since it had
to look at every frame for the UIC. It's a simple equation, more frames
more CPU to scan them for their UIC. Our performance area noticed that
there was an increase. I believe that it showed up as uncaptured CPU or
MVS usage under OMEGAMON CPU utilization. 


Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 9:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

But in z/OS 1.7 which kind of problem(s)  did you have ? 

Max Scarpa 



This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Max Scarpa]

But in z/OS 1.7 which kind of problem(s)  did you have ? 

Max Scarpa 





"Veilleux, Jon L" <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
07/11/2007 15.49
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Real storage usage  - a quick question






In z/OS 1.8 the memory management is much more conducive to large
memory. They no longer use the least recently used algorithm and no
longer check every page. This has made a big difference for us. Under
1.7 we had issues with large real memory sizes due to the constant
checking by RSM. This is no longer the case and we have increased our
memory dramatically with no performance hit.



Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 9:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Hi Martin how is it ?

We're in V7, I suppose you warned about 2 Gb limit. If the case, I can
assure you we're quite far from 2GB limit...

Anyway you've said that there were highly variable results (in tests and
in late 80s) which means that sometime things went better and sometimes
things worsened (about cpu usage I presume). Is it correct ?

Max Scarpa

 



This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Max Scarpa]

Hi Tom and thank you a lot for your reply.

WLC is a thing I cannot influence as it's managers' decision. But not 
using storage you bought and could be very useful seems to me a waste of 
money without a valid reason. Using it could increase performance and save 
some CPU to be used for customers. Sometime our capping is so long 
that all jobs are delayed a lot, expecially batch.

Thank you again and best regards

Max Scarpa







"Kelman, Tom" <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
07/11/2007 14.51
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Real storage usage  - a quick question






Here is how I see the answers to the naysayers.

1.  The CPU overhead incurred because of the addition of memory blocks
would be minimal and you'd probably actually buy back CPU overhead
because of things such as less I/O.  Adding more memory blocks would
allow you to retain more data in memory (DB2 buffers for example) and
reduce I/O.  In my mind I/O overhead would be a lot more CPU intensive
than any memory overhead.
2.  Yes, increasing the memory would probably cause the workload to
increase slightly.  There is always a tit-for-tat situation where you
fix one bottleneck in a system another will pop up.  However, it sounds
like your limiting your CPU usage based on software costs.  While I
understand the budget thing you also have to decide if you're hurting
your customers by doing that.  Is your DB2 processing so slow because of
the lack of memory that your customers are complaining?
3.  So you're paying for 5GB of storage that you aren't using.  Is that
really a good use of budget resources?

> Sent: Wednesday, November 07, 2007 4:00 AM by Max Scarpa
> 
> Esteemed listers
> 
> I've a problem but I haven't any answer to it or better I've different
> answers.
> 
> Say we have a machine with, just to say, 10 Gb of real storage. Only 5
are
> used by the only LPAR defined (actually there's  another very small
LPAR,
> but it's real small), which is a WLC LPAR and often it's CPU capped.
5 Gb
> remain unused. I asked why, as I'd like to enlarge my bufferpools in
DB2
> (for instance).  I've got these answers:
> 
> - Increasing real storage increases cpu overhead to managed more
memory
> blocks in a cpu-constrained machine.
> - Increasing real storage causes more workload so more chanches to hit
WLC
> capping.
> - It's better to have some spare storage (5 Gb ?).
> 
> Our workload is increasing and we have some occasional paging spikes.
DB2
> doesn't perform well due to too small pools.
> 
> According listers' experience, is using the most part/all real
storage
> (perhaps with a spare memory for future incrases) a real problem ? Did
> anyone experimented any problem ? What are guidelines ?
> 
> Thank you in advance
> 
> Max Scarpa
> 




*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Ted MacNEIL]

>- Increasing real storage increases cpu overhead to managed more memory. 
>blocks in a cpu-constrained machine.

It's cheaper to manage storage than it is to page.
I've always found the CPU overhead vs memory argument bogus.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Veilleux, Jon L]

In z/OS 1.8 the memory management is much more conducive to large
memory. They no longer use the least recently used algorithm and no
longer check every page. This has made a big difference for us. Under
1.7 we had issues with large real memory sizes due to the constant
checking by RSM. This is no longer the case and we have increased our
memory dramatically with no performance hit.



Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, November 07, 2007 9:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Real storage usage - a quick question

Hi Martin how is it ?

We're in V7, I suppose you warned about 2 Gb limit. If the case, I can
assure you we're quite far from 2GB limit...

Anyway you've said that there were highly variable results (in tests and
in late 80s) which means that sometime things went better and sometimes
things worsened (about cpu usage I presume). Is it correct ?

Max Scarpa

 



This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Kelman, Tom]

Here is how I see the answers to the naysayers.

1.  The CPU overhead incurred because of the addition of memory blocks
would be minimal and you'd probably actually buy back CPU overhead
because of things such as less I/O.  Adding more memory blocks would
allow you to retain more data in memory (DB2 buffers for example) and
reduce I/O.  In my mind I/O overhead would be a lot more CPU intensive
than any memory overhead.
2.  Yes, increasing the memory would probably cause the workload to
increase slightly.  There is always a tit-for-tat situation where you
fix one bottleneck in a system another will pop up.  However, it sounds
like your limiting your CPU usage based on software costs.  While I
understand the budget thing you also have to decide if you're hurting
your customers by doing that.  Is your DB2 processing so slow because of
the lack of memory that your customers are complaining?
3.  So you're paying for 5GB of storage that you aren't using.  Is that
really a good use of budget resources?

> Sent: Wednesday, November 07, 2007 4:00 AM by Max Scarpa
> 
> Esteemed listers
> 
> I've a problem but I haven't any answer to it or better I've different
> answers.
> 
> Say we have a machine with, just to say, 10 Gb of real storage. Only 5
are
> used by the only LPAR defined (actually there's  another very small
LPAR,
> but it's real small), which is a WLC LPAR and often it's CPU capped.
5 Gb
> remain unused. I asked why, as I'd like to enlarge my bufferpools in
DB2
> (for instance).  I've got these answers:
> 
> - Increasing real storage increases cpu overhead to managed more
memory
> blocks in a cpu-constrained machine.
> - Increasing real storage causes more workload so more chanches to hit
WLC
> capping.
> - It's better to have some spare storage (5 Gb ?).
> 
> Our workload is increasing and we have some occasional paging spikes.
DB2
> doesn't perform well due to too small pools.
> 
> According listers' experience, is using the most part/all real
storage
> (perhaps with a spare memory for future incrases) a real problem ? Did
> anyone experimented any problem ? What are guidelines ?
> 
> Thank you in advance
> 
> Max Scarpa
> 




*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Max Scarpa]

Hi Martin how is it ?

We're in V7, I suppose you warned about 2 Gb limit. If the case, I can 
assure you we're quite far from 2GB limit...

Anyway you've said that there were highly variable results (in tests and 
in late 80s) which means that sometime things went better and sometimes 
things worsened (about cpu usage I presume). Is it correct ?

Max Scarpa

 




Martin Packer <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
07/11/2007 15.23
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Re: Real storage usage  - a quick question






Two things

Caution about any case resting on saving CPU by eliminating I/O. Back in 
the late 1980s a series of IBM studies showed highly variable results in 
this area. Though the technology has (at least in part) rolled a number of 

times I'd still take home the same lesson.
In z/OS R.8 the cost of memory management got improved because of the RSM 
rewrite. I'd hazard that any management cost scaled better with memory 
size... As that was the whole point of the rewrite.

Oh, alright then, three things... :-)

Caution should be applied on DB2 Virtual Storage when scaling the buffer 
pools up - if you're on DB2 Version 7.

Martin

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Real storage usage - a quick question

[Martin Packer]

Two things

Caution about any case resting on saving CPU by eliminating I/O. Back in 
the late 1980s a series of IBM studies showed highly variable results in 
this area. Though the technology has (at least in part) rolled a number of 
times I'd still take home the same lesson.
In z/OS R.8 the cost of memory management got improved because of the RSM 
rewrite. I'd hazard that any management cost scaled better with memory 
size... As that was the whole point of the rewrite.

Oh, alright then, three things... :-)

Caution should be applied on DB2 Virtual Storage when scaling the buffer 
pools up - if you're on DB2 Version 7.

Martin

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[EMAIL PROTECTED]







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Real storage usage - a quick question

[Max Scarpa]

Esteemed listers

I've a problem but I haven't any answer to it or better I've different 
answers. 

Say we have a machine with, just to say, 10 Gb of real storage. Only 5 are 
used by the only LPAR defined (actually there's  another very small LPAR, 
but it's real small), which is a WLC LPAR and often it's CPU capped.  5 Gb 
remain unused. I asked why, as I'd like to enlarge my bufferpools in DB2 
(for instance).  I've got these answers:

- Increasing real storage increases cpu overhead to managed more memory 
blocks in a cpu-constrained machine. 
- Increasing real storage causes more workload so more chanches to hit WLC 
capping. 
- It's better to have some spare storage (5 Gb ?). 

Our workload is increasing and we have some occasional paging spikes. DB2 
doesn't perform well due to too small pools. 

According listers' experience, is using the most part/all real  storage 
(perhaps with a spare memory for future incrases) a real problem ? Did 
anyone experimented any problem ? What are guidelines ? 

Thank you in advance

Max Scarpa




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

I was into the “who cares?” mentality early.
But, others weren't.
The questions on the table, gentle-beings, are:

1. Are your goals being met?
2. Are your SLA's being met?

If the answers are “YES” (#2 being more important), go do something else.

If the answers are “NO”, the question is:

3. Are your business processes being impacted?

If the answer is “NO”, go do something else.

If the answer is “YES”, the question is:

4. What can I do to fix it.


The question is NEVER what is a 'BAD', or too 'HIGH', goal.
Goals are relative to each other, NOT absolutes.

The real answer is:

We do what we have to, to get the job done.

Rules Of Thumb do NOT rule!

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Shane Ginnane]

Trying to gently veer this thread back on course, unlike everyone else my
reaction is "who cares ???".

If CICS regions are (as I would expect) managed via transaction goals, high
(generally unmet) velocity goals are meaningless.
We set ours high to help startup/shutdown, then forget about them.


Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>That was changed in OS/390 R8 - R10 (via PTF).  A long time ago
now. There is another thread already referencing R8 of z/OS.
...

Sigh! YES! I know.
My point was not about values, rather the achievement of goals.
As usual, IBM-Main goes on about the side comments.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Mark Zelden]

On Wed, 28 Sep 2005 00:00:00 GMT, Ted MacNEIL
<[EMAIL PROTECTED]> wrote:


>We implemented Goal Mode when DISCONNECT counted as part of using.
>So, when we turned IO on, our velocities went up.

That was changed in OS/390 R8 - R10 (via PTF).  A long time ago
now. There is another thread already referencing R8 of z/OS.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>I dunno.  I could easily design a cpu intensive workload (branch on
count, anyone?) that could achieve and maintain a very high velocity for
very long periods of time
...
Artificial workloads don't count! (8-{]}

But, if I ever worked in a shop with a lot of engineering type work I might 
have said otherwise.

What part of 'empirical' do you not understand.

Besides, I eventually have to do IO.

But, this is an aside.
My point was/is: not the value; the acheivement is what counts.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>Is it safe to translate the "sometimes" to "once PI > 4"?
...

I've been involved in situations where the PI was less than 4, but nothing 
could be done to fix it.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>Huh?! With I/O priority management off, it doesn't matter.  With it
on it can only lower the velocity (if there are delays), not make
it higher.
...
I/O 'using' also counts.
And, if it's higher than delay, you will get higher velocity.
Especially, with a responsive DASD farm.

We implemented Goal Mode when DISCONNECT counted as part of using.
So, when we turned IO on, our velocities went up.
And, when we turned on Dynamic PAV's, it went up again.

My point was/is not so much the value of the velocity.
Can you achieve it?
If not, why not?
If you have to, fix it!

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Gerhard Adam]

>>Empirically, if you don't have I/O as part of the velocity equation,
>>you can never achieve a velocity of more that 45-50.

>What do you base this statement on?

...
>Empirical evidence.
>Statements from one of IBM's Canadian Performance Guru.


Well .. I hate to disagree but I've got plenty of reports showing
service classes with no I/O velocities getting velocities of over 90%.
I'm afraid that there is absolutely nothing that restricts such a
velocity ... Empirical or otherwise.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Diehl, Gary (MVSSupport)]

I dunno.  I could easily design a cpu intensive workload (branch on
count, anyone?) that could achieve and maintain a very high velocity for
very long periods of time.  I could pretty much guarantee that it could
get over 80% using samples during just about any period, provided it was
given a high enough importance.

I'd expect calculation-heavy engineering jobs to perform in a similar
manner.

I would agree, however, that any I/O heavy workload would struggle to
ever cap 50% velocity and stay there.

Gary

p.s. I hesitate to say never anymore, though I do still use the word
occasionally.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Ted MacNEIL
Sent: Tuesday, September 27, 2005 7:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: A quick question about velocity goals set high


>Empirically, if you don't have I/O as part of the velocity equation,
you can never achieve a velocity of more that 45-50.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>Empirically, if you don't have I/O as part of the velocity equation,
you can never achieve a velocity of more that 45-50.

What do you base this statement on?

...
Empirical evidence.
Statements from one of IBM's Canadian Performance Guru.
-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Gerhard Adam]

>> If you set it to high, any goal will be unachievable. And, sometimes 
>> the
>>SRM/WLM tandem will throw up its (metiphorical) 
>> hands, in disgust, and do nothing for the workload.

>Is it safe to translate the "sometimes" to "once PI > 4"? 

Actually WLM will set an indicator that will result in that service
class being skipped for several policy adjustment intervals.  So if
there is nothing that can be done to improve a PI, then the service
class is largely ignored.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Yifat]

> If you set it to high, any goal will be unachievable. And, sometimes the
SRM/WLM tandem will throw up its (metiphorical) 
> hands, in disgust, and do nothing for the workload.

Is it safe to translate the "sometimes" to "once PI > 4"? 

Yifat.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Mark Zelden]

On Wed, 28 Sep 2005 00:00:00 GMT, Ted MacNEIL
<[EMAIL PROTECTED]> wrote:

>>Is still bad to put velocity goals higher than 80% ? In IMHO it is.
>...
>
>Empirically, if you don't have I/O as part of the velocity equation, you
can never achieve a velocity of more that 45-50.
>
>With I/O, the issue is not what you set it to. Rather, can you achieve it.
>

Huh?! With I/O priority management off, it doesn't matter.  With it
on it can only lower the velocity (if there are delays), not make
it higher.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Gerhard Adam]

>Empirically, if you don't have I/O as part of the velocity equation,
you can never achieve a velocity of more that 45-50.

What do you base this statement on?  

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Gerhard Adam]

>I have to agree, an unattainable goal is an invalid goal.

>If you're getting a PI of 1.4 to 2 (or higher) that likely means that
the work that is running in that particular service class is actually
getting a >velocity of 64 (at best ~ 1.4 PI) down to 45 or worse (at >=
2 PI).

>We don't have any velocities over 50 for anything, no matter how
important.  Most of them are around 30 for started tasks.  If it's so
important that it >needs the highest priority, it goes to SYSSTC.

I think it should be noted that a goal that is too low is equally
invalid.  Goals should be set according to what a workload needs to meet
its real world objectives and not according to what one "hopes" to get.
Unattainable goals simply result in the workload being largely ignored
by WLM, while goals that are too easily achieved will result in
resources being taken away when other service classes need more.  The
latter case can be easily overlooked when there is no constraint.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Ted MacNEIL]

>Is still bad to put velocity goals higher than 80% ? In IMHO it is.
...

Empirically, if you don't have I/O as part of the velocity equation, you can 
never achieve a velocity of more that 45-50.

With I/O, the issue is not what you set it to. Rather, can you achieve it.

If you set it to high, any goal will be unachievable. And, sometimes the 
SRM/WLM tandem will throw up its (metiphorical) hands, in disgust, and do 
nothing for the workload.

If you need to achieve a goal, and aren't, find our why.
And, fix it.

Setting arbitrary rules (of thumb) and sticking to them is not performance 
analysis.


-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Diehl, Gary (MVSSupport)]

Max,

I have to agree, an unattainable goal is an invalid goal.

If you're getting a PI of 1.4 to 2 (or higher) that likely means that
the work that is running in that particular service class is actually
getting a velocity of 64 (at best ~ 1.4 PI) down to 45 or worse (at >= 2
PI).

We don't have any velocities over 50 for anything, no matter how
important.  Most of them are around 30 for started tasks.  If it's so
important that it needs the highest priority, it goes to SYSSTC.

It sounds like a good review of your goals, importance levels, and
actual service levels (i.e. how workloads and service classes are
performing now) is in order.

It gets even more fun if you're attempting to balance across a CECPLEX
for IRD and ensure adequate performance for high importance workloads at
100% physical busy times.

Best regards,

Gary Diehl

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Max Scarpa
Sent: Wednesday, September 28, 2005 8:25 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: A quick question about velocity goals set high


Estimeed lister

I'm in a shop were I see for some subsystems (CICS,CONTROM etc) a very
high
velocity goal, that is 90%. PIs range from 1.4 to > 2 and it NEVER
reaches
1 nor it's below 1.

I read some pepres that a very high velocity goal (>80%) is not good if
not
useless and infact in my previous shop in some CICS we lowered our goals
without any delay in response time.

Is still bad to put velocity goals higher than 80% ? In IMHO it is.

Thank you in advance

Max Scarpa

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Max Scarpa]

Thank you all for reply.

No, I see that our (or better 'their') goals are NEVER reached, PIs are
constantly above 1 (sometimes very above). I'm monitoring it since a many
weeks. In my opinion the system is stressed trying to reach these goals but
these goals are NOT set for CICS only but for many others AS (21) and for
this reason it's not possible to say that goals are high because they are
applied to 'loved ones' that, by definition, cannot be ALL CICS regions.
For this and other reason I think the goal is wrong in THIS environment.

Anyway in a previous shop I tested very high velocity but the difference
between a goal of 90% and a goal of 70% was minimum for batch jobs and not
so high for 1 or 2 CICS. Infact we had CICS velocity goals ranging from
30% to 50%.

Thank you again and best regards
Max Scarpa

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Fletcher, Kevin]

Max,

I am going to use the IBM reason, "It depends...". WLM is relative to
what your other goals are set to. It also depend on what importance you
set the velocity go to. A high velocity with and importance of 1 will
react a lot diffenently than a high velocity goal and an importance of
5. 

In the situation you stated the goal was designed to never be met so for
the most part will get the resources it needs. Is this a good thing?
Again, it depends.

IMHO a high velocity goal is not a good thing, but again it depends on
your other goals.

Thanks,
 
Fletch


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Max Scarpa
Sent: Wednesday, September 28, 2005 8:25 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: A quick question about velocity goals set high


Estimeed lister

I'm in a shop were I see for some subsystems (CICS,CONTROM etc) a very
high velocity goal, that is 90%. PIs range from 1.4 to > 2 and it NEVER
reaches 1 nor it's below 1.

I read some pepres that a very high velocity goal (>80%) is not good if
not useless and infact in my previous shop in some CICS we lowered our
goals without any delay in response time.

Is still bad to put velocity goals higher than 80% ? In IMHO it is.

Thank you in advance

Max Scarpa

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Mark Zelden]

On Wed, 28 Sep 2005 15:24:54 +0200, Max Scarpa <[EMAIL PROTECTED]> wrote:
>
>I'm in a shop were I see for some subsystems (CICS,CONTROM etc) a very high
>velocity goal, that is 90%. PIs range from 1.4 to > 2 and it NEVER reaches
>1 nor it's below 1.
>
>I read some pepres that a very high velocity goal (>80%) is not good if not
>useless and infact in my previous shop in some CICS we lowered our goals
>without any delay in response time.

Not necessarily true.   I've been at shops with CICS regions that have
a very high velocity goal (90) for some loved regions and were able to
make that goal.  It all depends on the environment.
>
>Is still bad to put velocity goals higher than 80% ? In IMHO it is.
>

No, it's bad to define unatainable goals - period.   This is what
you have in your shop according to what you wrote.

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A quick question about velocity goals set high

[Dave Thorn]

I think you have answered your own question.   The velocity is set so high
that it's unreachable.   My velocity goal for CICS and similar tasks is 40.
And things are fine.

__

Dave Thorn * Senior Technology Analyst * SunGard Computer Services * 600
Laurel Oak Road, Voorhees, NJ, 08043
Tel 856 566-5412 * Mobile 609 781-0353 * Fax 856 566-3656

CONFIDENTIALITY:  This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this e-mail in error,
please notify the sender and delete this e-mail from your system.



Estimeed lister

I'm in a shop were I see for some subsystems (CICS,CONTROM etc) a very high
velocity goal, that is 90%. PIs range from 1.4 to > 2 and it NEVER reaches
1 nor it's below 1.

I read some pepres that a very high velocity goal (>80%) is not good if not
useless and infact in my previous shop in some CICS we lowered our goals
without any delay in response time.

Is still bad to put velocity goals higher than 80% ? In IMHO it is.

Thank you in advance

Max Scarpa

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

A quick question about velocity goals set high

[Max Scarpa]

Estimeed lister

I'm in a shop were I see for some subsystems (CICS,CONTROM etc) a very high
velocity goal, that is 90%. PIs range from 1.4 to > 2 and it NEVER reaches
1 nor it's below 1.

I read some pepres that a very high velocity goal (>80%) is not good if not
useless and infact in my previous shop in some CICS we lowered our goals
without any delay in response time.

Is still bad to put velocity goals higher than 80% ? In IMHO it is.

Thank you in advance

Max Scarpa

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html