This may sound like a CICS question, but it is about the cost of doing I/O.
We have a CICS application that is doing upwards of 2000 I/O's per second to a
single VSAM file.
The entire CICS region is using 4.5% of a z/990 2084-309.
The CICS buffer hit ratio is around 60%, after we doubled the numb
What was the CPU utilization after the cache hit ration was 98%?
Ted MacNEIL <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List
04/09/2006 08:00 PM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
A very basic question
This may sound
How about Batch LSR (BLSR) or HIPERBAT
??
We have a CICS application that is doing upwards of 2000 I/O's per
second to a single VSAM file.
The entire CICS region is using 4.5% of a z/990 2084-309.
The CICS buffer hit ratio is around 60%, after we doubled the number of
buffers (can't do that too
guidine, these days?
I haven't done this kind of analysis in over 15 years.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
-Original Message-
From: "Ted MacNEIL" <[EMAIL PROTECTED]>
Date: Mon, 10 Apr 2006 17:29:23
To:"Mainframe Discussion List, IBM"
Su
On Mon, 10 Apr 2006 00:00:00 GMT, Ted MacNEIL wrote:
>This may sound like a CICS question, but it is about the cost of doing I/O.
>
>We have a CICS application that is doing upwards of 2000 I/O's per second
>to a single VSAM file.
>The entire CICS region is using 4.5% of a z/990 2084-309.
>The CICS
>How about Batch LSR (BLSR) or HIPERBAT
We don't have enough memory for that option.
Remember, this is a small CICS subsystem (4.5% of a 309).
And, it's doing 2000 I/O's per second to a single file.
And, it's CICS!
Batch LSR or HIPERBATCH cannot help it.
Also, for the poster that asked about CPU
One poster talked about CMDT and that is a good thought. But if the file can't
fit into CMDT what about looking at Innovation's IAM product? It can do some
wonderful things in relation to reduced CPU, I/O, and DASD space.
>>> [EMAIL PROTECTED] 4/9/2006 8:00:00 PM >>>
>How about Batch LSR (BLSR
Ted MacNEIL wrote:
Also, for the poster that asked about CPU usage.
Who cares? This entire CICS sub-system is using less than 5% of the processor.
The only one being impacted is this sub-system.
CICS cannot sustain that rate very long without response implications.
We need to know the cost per I
Trial IAM?
http://www.fdr.com/products/iam/index.cfm
-Original Message-
We have run out of all tuning options, save one.
Replace or remove the application.
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privil
Hi Ted:
For what is the 60% buffer hit ratio? Is it for the data? Is it for the
index? Or is it for both? If you have a 3 level file, and you are only
getting a 60% hit ratio, then it you are doing an average of 1.6 I/Os
per request. From a bird's eye view, you go from the application to
CICS m
>Trial IAM?
Not an option in an industry with tight margins and the belief that the
mainframe is already too 'expensive'.
It took me 16 months to justify MXG & SAS.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
--
For IBM-MAIN
>So, a savings of 10K instructions (I/O cost minus look-aside cost) is
>feasible.
Thanks for the review.
I haven't done this kind of analysis for over 15 years.
I still think it's an application design problem, but the vendor has us by the
short ones.
There is no other packaged alternative.
Bu
The VSAM buffer logic isn't that smart - one transaction that does scan of
thousands of records will flush the buffers.
If you have the memory and file size is small enough, a user maintained data
table will keep the entire structure in memory.
The other thing you might consider is making the ci si
>The other thing you might consider is making the ci size = 32K.
I have no control of the VSAM component sizes.
It's a canned product.
We either use it (business need) or we don't (justification required).
I've been a performance/capacity analyst/storage admin since 1981.
I do know the options.
You might even consider a REPRO to a flat file and then potentially import
to a RDBMS!!!
Rob Weiss
z/SWITA and z/Series I/T Security and Privacy Consultant
IBM Software Group Sales
IBM Mainframe Discussion List wrote on 04/09/2006
06:00:00 PM:
> >The other thing you might consider is making the
>You might even consider a REPRO to a flat file and then potentially import to
>a RDBMS!!!
Yes, but.
That's a re-development effort.
We are trying to size this.
We need information on resource needs.
I have already suggested CDMT, DB2, buffering increases, home grown, different
vendor.
The prob
In a message dated 4/10/2006 2:42:03 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>So, a savings of 10K instructions (I/O cost minus look-aside cost) is
>feasible.
I am very curious as to where the 10K number of instructions per I/O came
from. About 10 years ago I traced a simpl
In a message dated 4/10/2006 3:44:10 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>We keep it, or we justify delete or re-write.
...
>Buying new products is not, unfortunately.
Assume the cost of the new product is X. Does management understand that Y,
the cost of re-writing, is
>About 10 years ago I traced a simple MVS DASD EXCP under VM and counted
about 2,500 instructions
There's a difference between a simple DASD EXCP and VSAM I/O.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
--
For IBM-MAIN subs
In a message dated 4/11/2006 8:32:54 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>There's a difference between a simple DASD EXCP and VSAM I/O.
I do not believe that VSAM I/O's path length is twice that of EXCP. From
what point does the VSAM I/O start? I started tracing at the
>Where did the number 10K come from?
>What was measured?
It came from IBM over 20 years ago.
If you look at my original post, I was asking if it was valid. Not stating it
as a fact.
So far, I've gotten a lot of tuning recommendations and a maybe.
None of that has answered my question.
We a
"Mike Bell" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> The VSAM buffer logic isn't that smart - one transaction that does scan
of
> thousands of records will flush the buffers.
Not true. For LSR the buffers are maintained, they are not discarded as a
result of a search. I
>"What does it cost, in instructions (approximately) to do a VSAM I/O?"
I think you need to expand that question to:
1. what does it cost to do a VSAM I/O to real disk (or cache in your case,
since the hit ratio is almost 100%)?
2. what does it cost to do a VSAM I/O but finds a hit in a memory bu
>I think you need to expand that question to:
>1. what does it cost to do a VSAM I/O to real disk (or cache in your case,
since the hit ratio is almost 100%)?
The same as the cost going to disk -- it's just faster.
>2. what does it cost to do a VSAM I/O but finds a hit in a memory buffer?
The s
>Hence, the question on cost for an I/O.
>Since we are in an out-sourced arrangement, MIPS have a real cost.
>So, does anybody have an answer?
>Or, do we just continue to dance?
Assuming all things equal in an ideal world, the cpu usage by this app
would be constant, the R/T would be constant, t
A couple of repro's with delete define for some different ci sizes will give
you enough data points to answer the esential question.
What does it cost to do a VSAM IO from CICS at Ted's shop?
Mike
--
For IBM-MAIN subscribe / sign
M-MAIN@BAMA.UA.EDU
cc
Subject
Re: A very basic question
So, does anybody have an answer?
Or, do we just continue to dance?
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
--
For IBM-MAIN subscribe / signoff / archive access i
consume CPU. There is
no free lunch here.
HTH.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Monday, April 10, 2006 7:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: A very basic question
>Where did the number 10K come f
>Given that performance is erratic, but cpu usage is
consistently less than 5%, then it would seem it's more a question of I/O
waits, not I/O processing. I would look at resource contention, e.g.
channel, device, etc.
There is no contention unless you consider 2000 I/O's contentious. OMEGAMON
>I wonder what you would gain by knowing the answer to your question.
It's one of many factors in the business case.
The CPU consumption at 10K instructions costs us $90K (US) per annum from our
out-sourcer.
I mentioned this in a previous post.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
tuning, and management (along with workload profiling)
work evolved into capacity planning.
ref:
http://www.garlic.com/~lynn/2006f.html#22 A very basic question
for a little more drift ... when the US hone datacenters were
consolidated into a single center in the bayarea in the late 70s ...
possibl
"Ted MacNEIL" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
>
> >If this region uses less than 5% of cpu, and the end-users do not
complain about R/T, then do you really have problem?
>
> Ah, there's the key.
> My original post stated that response was occasional erratic, and us
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
>
> >Given that performance is erratic, but cpu usage is
> consistently less than 5%, then it would seem it's more a
> question of I/O waits, not I/O processing. I would look at
> resource contention, e.
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Thomen
>
> [ snip ]
>
> You haven't described the application - 2K reads? 2K writes?
> 2K mixed reads/writes? Is the app trying to retrieve
> records that are being updated? Is the device shared with
> oth
>You haven't described the application - 2K reads? 2K writes? 2K mixed
reads/writes? Is the app trying to retrieve records that are being
updated?
100% reads. 4K. No updates.
>Is the device shared with other systems?
Yes, but nobody else but this CICS sub-system is touching the file. The I/O
>>No, the problem is that your CICS region is not properly tuned to handle
that many BROWSEs.
Possibly.
But, how do you handle 2000 I/O's per second.
>> The solution is to reduce the I/O.
>Since you've dismissed all the suggestions offered
I have not dismissed them,
They are all already made.
B
I cannot answer your question. I understand that the application is a
"black box" and you cannot look inside it. In one post, you stated that
the "cost" for a cache lookup (I guess in terms of instructions) is
identical to the "cost", in instructions, for a DASD I/O, only "faster"
(less elapsed tim
Ted MacNEIL wrote:
I think you need to expand that question to:
1. what does it cost to do a VSAM I/O to real disk (or cache in your case,
since the hit ratio is almost 100%)?
The same as the cost going to disk -- it's just faster.
2. what does it cost to do a VSAM I/O but finds a hit in a m
>From what you've described it appears that this transaction can be divided up
>into a certain amount of CPU time to process the transaction and then an
>amount used to drive/manage the I/O. If that's the case, and the CPU consumed
>for the transaction is relatively constant, you can approximat
Ted,
A general technique I have used successfully to estimate the CPU usage (or
instruction path length) of a "black box" piece of code is as follows:
(1) Measure the resource usage of the standard job - call this R1
(2) Modify the job (in the case your COBOL program) to call the "black box"
s
In <[EMAIL PROTECTED]>, on 04/11/2006
at 09:43 AM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:
>I also believe that VSAM uses EXCPVR,
AFAIK it uses STARTIO, which has a shorter path length than EXCP or
even EXCPVR.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO
:[EMAIL PROTECTED] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Tuesday, April 11, 2006 7:49 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: A very basic question
In <[EMAIL PROTECTED]>, on 04/11/2006
at 09:43 AM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:
>I al
So, it seems that this package is used to perform some sort of computation
based on zip codes, or something along those lines. If this is the
primary (or part of) application on this CICS region, then it's quite
conceivable that during a peak period, the region is, in effect, doing a
lot of co
In a message dated 4/12/2006 5:46:05 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>AFAIK it uses STARTIO, which has a shorter path length than EXCP or
>even EXCPVR.
You're right. VSAM is officially defined as an IOS Driver in the IOSB DSECT
in the Driver ID field. Therefore VSA
I just pulled this from one of our CICS transactions:
Overall Elapsed time: 4.109s
*---ยท*
| Dispatch time . . . : 0.453s| Suspend time . . . . . . : 3.656s|
| QR
In
<[EMAIL PROTECTED]>,
on 04/12/2006
at 11:04 AM, "Knutson, Sam" <[EMAIL PROTECTED]> said:
>There have been some good discussions in the past which suggest that
>the DFP access methods don't use STARTIO directly.
Which DFP access methods? There's not much of a code overlap between
[B|D|I|Q]SA
There have been some good discussions in the past which suggest that the
DFP access methods don't use STARTIO directly.
Sam, that sounds like semantics. Most of the non-VSAM access methods
(xSAM, BPAM, BDAM) issue EXCP SVCs, and EXCP invokes STARTIO. In that
sense they are indirect. VSAM u
Hi:
Just to add some additional comments to this item:
The Hursley staff has stated at several conferences I have attended
(SHARE and the CICS Technical Conference) that a TCB switch (e.g., QR to
L8 (DB2)) within CICS takes around 2000 instructions or a round trip
4000 instructions. It would see
I don't remember any reduction in cpu instructions for VSAM just enhanced
functionality. One of the reasons DB2 uses the media manager interface.
You ddin't mention the transaction rate. Is this one transaction doing
batch workload? or lots of small transactions?
Since the cache hit ratio is 98%
One key point I forgot to mention.
It's a canned programme from a vendor, with few customisation options.
>You ddin't mention the transaction rate. Is this one transaction doing
batch workload? or lots of small transactions?
We cannot see under the covers, very well.
But, it uses browse to seek
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
>
> [ snip ]
>
> 100% read!
CMDT is the way to go, then.
-jc-
--
For IBM-MAIN subscribe / signoff / archive access instructions,
s
Sounds like Finalist.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ted MacNEIL
Sent: Sunday, April 09, 2006 8:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Fw: A very basic question
One key point I forgot to mention.
It's a canned prog
>Sounds like Finalist.
No, it's not.
My company is very paranoid about letting anything be known about them.
As a matter of fact, the articles I write for Mainframe Extra are only allowed
because I do not mention my company or their operational environment.
Because of that, I have been circumsp
No definitive answers by a long shot but another coupla straws to
consider grasping at.
-
On 2006-04-11 at 15:29, Ted MacNEIL <[EMAIL PROTECTED]> wrote
about "re: Cics Transaction I/O computation" to IBM-Main:
> >[snip]
> There is no contention unless you consider 2000 I/O's contentious.
> O
54 matches
Mail list logo
