-snip
BTW Why are you still doing VIO at all?
---unsnip
It still avoids the overhead of allocating and deleting a dataset on
real disk. For small datasets that go away at the end of the
Staller, Allan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
Can SYS1.STGINDEX (VIO journaling) have secondary allocations?
/snip
AFAIK, No.
BTW Why are you still doing VIO at all?
It made a lot of sense when disk access times were 17-30 ms, but not
with 3-4ms
The fastest I/O is the I/O you don't do.
I agree completely. BUT: Eliminating sys1.stgindex does NOT mean that you
cannot use VIO anymore. The SYS1.STGINDEX is used for checkpoint-restart of a
VIO dataset. How many installations do checkpoint-restart for VIO? (We
certainly don't. I eliminated
Is this that simple? The fastest I/O is the I/O you don't do. With VIO you
have a good chance to keep all data in storage, depending on the amount of
real storege, your UIC and your paging. But in modern systems I think you have
a good chance to eliminate all I/O with VIO datasets.
Remember,
Ted MacNEIL [EMAIL PROTECTED] wrote in message
news:1866030885-1215768126-cardhu_decombobulator_blackberry.rim.net-186
[EMAIL PROTECTED]...
Is this that simple? The fastest I/O is the I/O you don't do. With
VIO you have a good chance to keep all data in storage, depending on the
amount of real
But even so: the ROT is(was) if an instruction takes a second, an I/O takes 2
weeks.
Could 1 ms I/O responsetime even come near the break-even piont?
Considering that there is more than one instruction in the I/O path.
Considering that VIO's CPU requirement is larger.
Considering buffering.
The
Kees wrote:
snip
AFAIK, No.
BTW Why are you still doing VIO at all?
It made a lot of sense when disk access times were 17-30 ms, but not
with 3-4ms (Escon/Cache) or 1 ms (FICON/Cache)
Is this that simple? The fastest I/O is the I/O you don't do. With VIO
you have a good chance to keep
Staller, Allan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Kees wrote:
snip
AFAIK, No.
BTW Why are you still doing VIO at all?
It made a lot of sense when disk access times were 17-30 ms, but not
with 3-4ms (Escon/Cache) or 1 ms (FICON/Cache)
Is this that
On Thu, 10 Jul 2008 05:21:23 +, Jan Vanbrabant wrote:
Can SYS1.STGINDEX (VIO journaling) have secondary allocations?
No.
Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote:
Staller, Allan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Kees wrote:
snip
AFAIK, No.
BTW Why are you still doing VIO at all?
It made a lot of sense when disk access times were 17-30 ms, but not
with 3-4ms
On Fri, 11 Jul 2008 11:13:04 -0400, John Kington
[EMAIL PROTECTED] wrote:
No numbers but a story from personal experience. When I first implemented
SMS, I setup a VIO storage group with a limit of about 10 cylinders on a
3390 and made any requests over 10 cylinders go to dasd. About six years
Mark Zelden [EMAIL PROTECTED] wrote:
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/11/2008
12:04:33 PM:
On Fri, 11 Jul 2008 11:13:04 -0400, John Kington
[EMAIL PROTECTED] wrote:
No numbers but a story from personal experience. When I first
implemented
SMS, I setup a VIO
snip
Can SYS1.STGINDEX (VIO journaling) have secondary allocations?
/snip
AFAIK, No.
BTW Why are you still doing VIO at all?
It made a lot of sense when disk access times were 17-30 ms, but not
with 3-4ms (Escon/Cache) or 1 ms (FICON/Cache)
When I found that we were doing a CLPA at every
Hi listers ,
Can SYS1.STGINDEX (VIO journaling) have secondary allocations?
Jan
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the
14 matches
Mail list logo
