AW: Re: Whither VIO?

2016-05-16 Thread Peter Hunkeler 
>[snip] Expanded storage is one of those things that, for a combination of 
>technical and marketing reasons, had its day in the sun and has gone, while 
>VIO continues.


It's back, just called "Flash Express" these days. It's used for paging, and 
for some other things (or things to come) just as Expanded Storage was.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Martin Packer 
It's a simulated device and I guess 3314 is tiny. I vaguely recall - from 
more than 25 years ago - wanting to use a tiny one. I think it might be a 
limit on something - VIO data sets not being multivolume?

(I think this simulation is a significant part of the CPU cost for VIO.)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   Jesse 1 Robinson <jesse1.robin...@sce.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/05/2016 17:05
Subject:    Re: Whither VIO?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Mea culpa once again for misstating the facts. My shop does indeed still 
support VIO--under a different esoteric--but, as Ed Jaffe pointed out, 
with a pretty severe size limit. I looked through one PROCLIB for 
instances of VIO. I found it mostly in compile/link jobs with very small 
work files. 

As for DFSORT, our default ICEMAC includes VIO=YES, but I have no idea who 
would use it. In view of our low limit for VIO, I doubt that many SORTWK 
files would actually end up there.

One question I have. In a previous life, we defined VIO (I believe) to 
device 3314 even though we had none left on the floor. The device type was 
still valid in IOGEN at that time, and I was told that device architecture 
was more suitable for VIO than 3380. VIO here is currently defined to 
3390. Is there any difference? 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of David Betten
Sent: Wednesday, May 11, 2016 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Whither VIO?

When I was in DFSORT, I always recommended not using VIO for sort work 
data sets.  We felt it was better to let DFSORT manage the use of storage 
for intermediate work space via Hiperspace, Memory Object or Dataspace. 
One advantage was that DFSORT has controls over the total memory usage by 
concurrent sort applications.

I believe VIO is still something worth exploiting for other types of 
temporary data sets given the larger storage configurations available 
today.  However, keep in mind that there are also some limitations to VIO 
such as not supporting large format data sets.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
05/11/2016 11:10:55 AM:

> From: Martin Packer <martin_pac...@uk.ibm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/11/2016 11:12 AM
> Subject: Re: Whither VIO?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
> I said in another thread that VIO was one of the worse DIM exploiters 
> for

> CPU usage - in the Orange "Coffee Table" book of DIM studies way back 
> when.
>
> I've no reason to doubt it now. I would still expect that for many 
> uses
it
> is faster than temporary data sets on disk, though.
>
> So I would question what we're optimising for.
>
> And I would agree that a rival implementation - such as hiperspace or 
> 64-Bit Memory Object sorting - is worth investigating.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems 
> Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle):
> https://developer.ibm.com/tv/category/mpt/
>
>
>
> From:   "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/05/2016 15:32
> Subject:Re: Whither VIO?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> I heard rumors that VIO is that CPU expensive and that I/O is that 
> fast nowadays, that it is VIO is not worth the extra CPU anymore.
>
> Therefor I have been thinking about abandoning VIO, but I can't make a 
> good calculation. I could make the calculation for the SAS WORK file, 
> which can be in VIO or in HIPERSPACE. The latter is cheaper, as is 
> stated

> by SAS and it is easy to switch to Hiperspace with a simple 
> installation parameter.
>
> Does anyone has some figures on other use of VIO?
>
> K

Re: Whither VIO?

2016-05-11 Thread Paul Gilmartin 
On Wed, 11 May 2016 13:09:45 -0400, Tony Harminc wrote:
>
>The biggest reason to use VIO rather than the various alternatives
>mentioned is that it is compatible. An existing application need know
>nothing about it, and can be offered improved performance with no code
>changes. In these days of large memory it may seem quaint, but it has
>its place.
> 
Compatible.  I recall a time when IEBCOPY couldn't deal with VIO because
IEBCOPY used EXCP V=R, but VIO relying on paging could accept only
virtual addresses.  (Surprisingly?) this was addressed in VIO (by a sort
of reverse LRA/DAT?) rather than modifying IEBCOPY.  I wonder what the
cost, and whether nowadays IEBCOPY eschews EXCP V=R so it may run
with AC=0.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Tony Harminc 
On 11 May 2016 at 10:07, Martin Packer  wrote:
> The nasty answer to "what happened to VIO?" is "nothing". :-) :-(
>
> Seriously, it remains as before but implemented in central storage rather
> than expanded.

VIO long predates the existence of expanded storage. It was original
with MVS (2.0 in iirc 1972), and at the time there was nowhere for it
to go but the paging system. Expanded storage is one of those things
that, for a combination of technical and marketing reasons, had its
day in the sun and has gone, while VIO continues.

The biggest reason to use VIO rather than the various alternatives
mentioned is that it is compatible. An existing application need know
nothing about it, and can be offered improved performance with no code
changes. In these days of large memory it may seem quaint, but it has
its place.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Tony Harminc 
On 11 May 2016 at 12:05, Jesse 1 Robinson  wrote:
> One question I have. In a previous life, we defined VIO (I believe) to device 
> 3314 even though we had none left on the floor. The device type was still 
> valid in IOGEN at that time, and I was told that device architecture was more 
> suitable for VIO than 3380. VIO here is currently defined to 3390. Is there 
> any difference?

I'm not sure about the device architecture, but the traditional reason
for choosing a particular and perhaps obsolete device type for VIO was
to limit the space available. This was before SMS or any other
controls, and if you set up 3350 or 3380 as VIO device types, an
application could easily allocate and try to fill up the entire
virtual disk, with potentially disastrous results for the paging
system. One trick was to specify the VIO device as 2305 (the old
fixed-head disk, sometimes incorrectly called a "drum"), which was
very small - 5 or 10 MB, depending on the model. The 2314 was next on
the list - much bigger, but still only 30 MB or so. The 2311 or 2301
might have been an even better bet, but neither was ever supported on
MVS.

It may be that the "device architecture" is referring to the number of
4K pages needed to hold a track image for the device in question, with
how much wastage. It's kind of the opposite calculation to what makes
a good paging device, i.e. how many pages fit on a track with how much
left over.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Dana Mitchell 
I remember hearing in MVS Measurement & Tuning class way back,  choosing an 
older geometry such as 3330 or 3350 track size was preferred for VIO so as to 
use a smaller window for VIO to minimize precious central storage usage, as 
compared to the honkin' 3380 track size of 47kb.   Technology marches on!

Dana

On Wed, 11 May 2016 16:05:13 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
wrote:
>
>One question I have. In a previous life, we defined VIO (I believe) to device 
>3314 even though we had none left on the floor. The device type was still 
>valid in IOGEN at that time, and I was told that device architecture was more 
>suitable for VIO than 3380. VIO here is currently defined to 3390. Is there 
>any difference? 
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-302-7535 Office
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of David Betten
>Sent: Wednesday, May 11, 2016 8:41 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Whither VIO?
>
>When I was in DFSORT, I always recommended not using VIO for sort work data 
>sets.  We felt it was better to let DFSORT manage the use of storage for 
>intermediate work space via Hiperspace, Memory Object or Dataspace.  One 
>advantage was that DFSORT has controls over the total memory usage by 
>concurrent sort applications.
>
>I believe VIO is still something worth exploiting for other types of temporary 
>data sets given the larger storage configurations available today.  However, 
>keep in mind that there are also some limitations to VIO such as not 
>supporting large format data sets.
>
>
>Have a nice day,
>Dave Betten
>z/OS Performance Specialist
>Cloud and Systems Performance
>IBM Corporation
>email:  bet...@us.ibm.com
>
>
>IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
>05/11/2016 11:10:55 AM:
>
>> From: Martin Packer <martin_pac...@uk.ibm.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 05/11/2016 11:12 AM
>> Subject: Re: Whither VIO?
>> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>>
>> I said in another thread that VIO was one of the worse DIM exploiters 
>> for
>
>> CPU usage - in the Orange "Coffee Table" book of DIM studies way back 
>> when.
>>
>> I've no reason to doubt it now. I would still expect that for many 
>> uses
>it
>> is faster than temporary data sets on disk, though.
>>
>> So I would question what we're optimising for.
>>
>> And I would agree that a rival implementation - such as hiperspace or 
>> 64-Bit Memory Object sorting - is worth investigating.
>>
>> Cheers, Martin
>>
>> Martin Packer,
>> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems 
>> Performance, IBM
>>
>> +44-7802-245-584
>>
>> email: martin_pac...@uk.ibm.com
>>
>> Twitter / Facebook IDs: MartinPacker
>>
>> Blog:
>> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>>
>> Podcast Series (With Marna Walle):
>> https://developer.ibm.com/tv/category/mpt/
>>
>>
>>
>> From:   "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date:   11/05/2016 15:32
>> Subject:Re: Whither VIO?
>> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>>
>>
>>
>> I heard rumors that VIO is that CPU expensive and that I/O is that 
>> fast nowadays, that it is VIO is not worth the extra CPU anymore.
>>
>> Therefor I have been thinking about abandoning VIO, but I can't make a 
>> good calculation. I could make the calculation for the SAS WORK file, 
>> which can be in VIO or in HIPERSPACE. The latter is cheaper, as is 
>> stated
>
>> by SAS and it is easy to switch to Hiperspace with a simple 
>> installation parameter.
>>
>> Does anyone has some figures on other use of VIO?
>>
>> Kees.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Martin Packer
>> Sent: 11 May, 2016 16:08
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Whither VIO?
>>
>> The nasty answer to "what happened to VIO?" is "nothing". :-) :-(
>>
>> Seriously, it remains as before but implemented in central storage 
>> rather
>
>> than expanded.

Re: Whither VIO?

2016-05-11 Thread Jesse 1 Robinson 
Mea culpa once again for misstating the facts. My shop does indeed still 
support VIO--under a different esoteric--but, as Ed Jaffe pointed out, with a 
pretty severe size limit. I looked through one PROCLIB for instances of VIO. I 
found it mostly in compile/link jobs with very small work files. 

As for DFSORT, our default ICEMAC includes VIO=YES, but I have no idea who 
would use it. In view of our low limit for VIO, I doubt that many SORTWK files 
would actually end up there.

One question I have. In a previous life, we defined VIO (I believe) to device 
3314 even though we had none left on the floor. The device type was still valid 
in IOGEN at that time, and I was told that device architecture was more 
suitable for VIO than 3380. VIO here is currently defined to 3390. Is there any 
difference? 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Betten
Sent: Wednesday, May 11, 2016 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Whither VIO?

When I was in DFSORT, I always recommended not using VIO for sort work data 
sets.  We felt it was better to let DFSORT manage the use of storage for 
intermediate work space via Hiperspace, Memory Object or Dataspace.  One 
advantage was that DFSORT has controls over the total memory usage by 
concurrent sort applications.

I believe VIO is still something worth exploiting for other types of temporary 
data sets given the larger storage configurations available today.  However, 
keep in mind that there are also some limitations to VIO such as not supporting 
large format data sets.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
05/11/2016 11:10:55 AM:

> From: Martin Packer <martin_pac...@uk.ibm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/11/2016 11:12 AM
> Subject: Re: Whither VIO?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
> I said in another thread that VIO was one of the worse DIM exploiters 
> for

> CPU usage - in the Orange "Coffee Table" book of DIM studies way back 
> when.
>
> I've no reason to doubt it now. I would still expect that for many 
> uses
it
> is faster than temporary data sets on disk, though.
>
> So I would question what we're optimising for.
>
> And I would agree that a rival implementation - such as hiperspace or 
> 64-Bit Memory Object sorting - is worth investigating.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems 
> Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle):
> https://developer.ibm.com/tv/category/mpt/
>
>
>
> From:   "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/05/2016 15:32
> Subject:Re: Whither VIO?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> I heard rumors that VIO is that CPU expensive and that I/O is that 
> fast nowadays, that it is VIO is not worth the extra CPU anymore.
>
> Therefor I have been thinking about abandoning VIO, but I can't make a 
> good calculation. I could make the calculation for the SAS WORK file, 
> which can be in VIO or in HIPERSPACE. The latter is cheaper, as is 
> stated

> by SAS and it is easy to switch to Hiperspace with a simple 
> installation parameter.
>
> Does anyone has some figures on other use of VIO?
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Martin Packer
> Sent: 11 May, 2016 16:08
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Whither VIO?
>
> The nasty answer to "what happened to VIO?" is "nothing". :-) :-(
>
> Seriously, it remains as before but implemented in central storage 
> rather

> than expanded.
>
> With the improved economics of memory it's worth looking at again - 
> but only if memory is available to support it.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems 
> Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.i

Re: Whither VIO?

2016-05-11 Thread David Betten 
When I was in DFSORT, I always recommended not using VIO for sort work data
sets.  We felt it was better to let DFSORT manage the use of storage for
intermediate work space via Hiperspace, Memory Object or Dataspace.  One
advantage was that DFSORT has controls over the total memory usage by
concurrent sort applications.

I believe VIO is still something worth exploiting for other types of
temporary data sets given the larger storage configurations available
today.  However, keep in mind that there are also some limitations to VIO
such as not supporting large format data sets.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
05/11/2016 11:10:55 AM:

> From: Martin Packer <martin_pac...@uk.ibm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/11/2016 11:12 AM
> Subject: Re: Whither VIO?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
> I said in another thread that VIO was one of the worse DIM exploiters for

> CPU usage - in the Orange "Coffee Table" book of DIM studies way back
> when.
>
> I've no reason to doubt it now. I would still expect that for many uses
it
> is faster than temporary data sets on disk, though.
>
> So I would question what we're optimising for.
>
> And I would agree that a rival implementation - such as hiperspace or
> 64-Bit Memory Object sorting - is worth investigating.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle):
> https://developer.ibm.com/tv/category/mpt/
>
>
>
> From:   "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/05/2016 15:32
> Subject:Re: Whither VIO?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> I heard rumors that VIO is that CPU expensive and that I/O is that fast
> nowadays, that it is VIO is not worth the extra CPU anymore.
>
> Therefor I have been thinking about abandoning VIO, but I can't make a
> good calculation. I could make the calculation for the SAS WORK file,
> which can be in VIO or in HIPERSPACE. The latter is cheaper, as is stated

> by SAS and it is easy to switch to Hiperspace with a simple installation
> parameter.
>
> Does anyone has some figures on other use of VIO?
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 11 May, 2016 16:08
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Whither VIO?
>
> The nasty answer to "what happened to VIO?" is "nothing". :-) :-(
>
> Seriously, it remains as before but implemented in central storage rather

> than expanded.
>
> With the improved economics of memory it's worth looking at again - but
> only if memory is available to support it.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle):
> https://developer.ibm.com/tv/category/mpt/
>
>
>
> From:   Lizette Koehler <stars...@mindspring.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/05/2016 14:55
> Subject:Re: Whither VIO?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> My guess would be:
>
> DASD is faster
> Virtual Tape is faster
> Central Memory is plentiful (for some shops)
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> > Behalf Of Jerry Callen
> > Sent: Wednesday, May 11, 2016 6:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Whither VIO?
> >
> > In a thread in a distant galaxy, J.O.Skip Robinson wrote:
> >
> > > ...be aware that some customers (like us) did away with VIO a long
> time ago.
> >
> > I've been away from MVS for a while. Did something better than VIO come

> along
> > while I wasn't looking? Why would VIO have been vaporized?
> >
> > -- Jerry
> &

Re: Whither VIO?

2016-05-11 Thread Martin Packer 
I said in another thread that VIO was one of the worse DIM exploiters for 
CPU usage - in the Orange "Coffee Table" book of DIM studies way back 
when.

I've no reason to doubt it now. I would still expect that for many uses it 
is faster than temporary data sets on disk, though.

So I would question what we're optimising for.

And I would agree that a rival implementation - such as hiperspace or 
64-Bit Memory Object sorting - is worth investigating.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/05/2016 15:32
Subject:Re: Whither VIO?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



I heard rumors that VIO is that CPU expensive and that I/O is that fast 
nowadays, that it is VIO is not worth the extra CPU anymore. 

Therefor I have been thinking about abandoning VIO, but I can't make a 
good calculation. I could make the calculation for the SAS WORK file, 
which can be in VIO or in HIPERSPACE. The latter is cheaper, as is stated 
by SAS and it is easy to switch to Hiperspace with a simple installation 
parameter.

Does anyone has some figures on other use of VIO?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Martin Packer
Sent: 11 May, 2016 16:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Whither VIO?

The nasty answer to "what happened to VIO?" is "nothing". :-) :-(

Seriously, it remains as before but implemented in central storage rather 
than expanded.

With the improved economics of memory it's worth looking at again - but 
only if memory is available to support it.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   Lizette Koehler <stars...@mindspring.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/05/2016 14:55
Subject:Re: Whither VIO?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



My guess would be:

DASD is faster
Virtual Tape is faster
Central Memory is plentiful (for some shops)

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jerry Callen
> Sent: Wednesday, May 11, 2016 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Whither VIO?
> 
> In a thread in a distant galaxy, J.O.Skip Robinson wrote:
> 
> > ...be aware that some customers (like us) did away with VIO a long 
time ago.
> 
> I've been away from MVS for a while. Did something better than VIO come 
along
> while I wasn't looking? Why would VIO have been vaporized?
> 
> -- Jerry
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 
confidential and privileged material intended for the addressee only. If 
you are not the addressee, you are notified that no part of the e-mail or 
any attachment may be disclosed, copied or distributed, and that any other 
action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt. 
Koninklijke Luchtvaart Maatschappij N.

Re: Whither VIO?

2016-05-11 Thread Ed Jaffe 

On 5/11/2016 7:31 AM, Vernooij, CP (ITOPT1) - KLM wrote:

I heard rumors that VIO is that CPU expensive and that I/O is that fast 
nowadays, that it is VIO is not worth the extra CPU anymore.


We use VIO for (nearly) ALL temporary data sets. (VIO MAXSIZE is set to 
the highest supported value of 2G.) I haven't tried to compare VIO 
against DASD from a performance standpoint -- probably because we never 
noticed any issues with VIO.


For us it's a matter of convenience to have numerous, fairly large 
"DASD" work data sets that never, Ever, EVER experience VTOC data set 
naming conflicts or need scratching after a system failure. Another 
benefit to us is the ability to have a virtual 3380 device for testing 
code intended to be "DASD-geometry-agnostic" but might not be.


We recently uncovered an error with IBM's stand-alone ADRDSSU because we 
used a temporary 3380 device in the SABLD job. The error is not specific 
to 3380, it just happens to be reproducible right now on 3380 given the 
current module sizes. If the error is not fixed, the same problem could 
occur on 3390 if some PTF changes the sizes of the load modules just 
right...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Vernooij, CP (ITOPT1) - KLM 
I heard rumors that VIO is that CPU expensive and that I/O is that fast 
nowadays, that it is VIO is not worth the extra CPU anymore. 

Therefor I have been thinking about abandoning VIO, but I can't make a good 
calculation. I could make the calculation for the SAS WORK file, which can be 
in VIO or in HIPERSPACE. The latter is cheaper, as is stated by SAS and it is 
easy to switch to Hiperspace with a simple installation parameter.

Does anyone has some figures on other use of VIO?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: 11 May, 2016 16:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Whither VIO?

The nasty answer to "what happened to VIO?" is "nothing". :-) :-(

Seriously, it remains as before but implemented in central storage rather 
than expanded.

With the improved economics of memory it's worth looking at again - but 
only if memory is available to support it.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   Lizette Koehler <stars...@mindspring.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/05/2016 14:55
Subject:Re: Whither VIO?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



My guess would be:

DASD is faster
Virtual Tape is faster
Central Memory is plentiful (for some shops)

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jerry Callen
> Sent: Wednesday, May 11, 2016 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Whither VIO?
> 
> In a thread in a distant galaxy, J.O.Skip Robinson wrote:
> 
> > ...be aware that some customers (like us) did away with VIO a long 
time ago.
> 
> I've been away from MVS for a while. Did something better than VIO come 
along
> while I wasn't looking? Why would VIO have been vaporized?
> 
> -- Jerry
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Martin Packer 
The nasty answer to "what happened to VIO?" is "nothing". :-) :-(

Seriously, it remains as before but implemented in central storage rather 
than expanded.

With the improved economics of memory it's worth looking at again - but 
only if memory is available to support it.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   Lizette Koehler <stars...@mindspring.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/05/2016 14:55
Subject:Re: Whither VIO?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



My guess would be:

DASD is faster
Virtual Tape is faster
Central Memory is plentiful (for some shops)

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jerry Callen
> Sent: Wednesday, May 11, 2016 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Whither VIO?
> 
> In a thread in a distant galaxy, J.O.Skip Robinson wrote:
> 
> > ...be aware that some customers (like us) did away with VIO a long 
time ago.
> 
> I've been away from MVS for a while. Did something better than VIO come 
along
> while I wasn't looking? Why would VIO have been vaporized?
> 
> -- Jerry
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Whither VIO?

2016-05-11 Thread Lizette Koehler 
My guess would be:

DASD is faster
Virtual Tape is faster
Central Memory is plentiful (for some shops)

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jerry Callen
> Sent: Wednesday, May 11, 2016 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Whither VIO?
> 
> In a thread in a distant galaxy, J.O.Skip Robinson wrote:
> 
> > ...be aware that some customers (like us) did away with VIO a long time ago.
> 
> I've been away from MVS for a while. Did something better than VIO come along
> while I wasn't looking? Why would VIO have been vaporized?
> 
> -- Jerry
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN