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 +0000, Jesse 1 Robinson <[email protected]> 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 >[email protected] > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of David Betten >Sent: Wednesday, May 11, 2016 8:41 AM >To: [email protected] >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: [email protected] > > >IBM Mainframe Discussion List <[email protected]> wrote on >05/11/2016 11:10:55 AM: > >> From: Martin Packer <[email protected]> >> To: [email protected] >> Date: 05/11/2016 11:12 AM >> Subject: Re: Whither VIO? >> Sent by: IBM Mainframe Discussion List <[email protected]> >> >> 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: [email protected] >> >> 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" <[email protected]> >> To: [email protected] >> Date: 11/05/2016 15:32 >> Subject: Re: Whither VIO? >> Sent by: IBM Mainframe Discussion List <[email protected]> >> >> >> >> 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:[email protected]] >> On Behalf Of Martin Packer >> Sent: 11 May, 2016 16:08 >> To: [email protected] >> 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: [email protected] >> >> 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 <[email protected]> >> To: [email protected] >> Date: 11/05/2016 14:55 >> Subject: Re: Whither VIO? >> Sent by: IBM Mainframe Discussion List <[email protected]> >> >> >> >> 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:[email protected]] >On >> > Behalf Of Jerry Callen >> > Sent: Wednesday, May 11, 2016 6:51 AM >> > To: [email protected] >> > 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
