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 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. <</snip>> Everything is relative my son! VIO only eliminates some of the I/O (associated w/allocation). Under the covers VIO is a data windowing system backed by aux storage. Physical I/O is may still occur for the data, depending on the size. Granted the I/O is processed w/less overhead since the paging subsystem is used instead of IOS. This, of course led to other issues... TAANSTAAFL With all of the other improvements IBM has made in allocation processing (cached VTOCS, VTOC indexing, SMS, ...), the advantage is even less. My experience agrees w /Ted's response. With physical I/O trending < 1ms, the relative benefits of VIO today are highly questionable. A quick dive into history (Shmuel, Lynn, jump in here and help me out): When VIO was created, Physical I/O was in the 30-50 ms range (3330/3350 uncached dasd). (IIRC 3350 was 17 ms average, 30 ms max; 3330 was double that). A *large* machine was 4MB. The perceived time benefits of VIO outweighed the costs of the physical I/O for allocation and the associated CPU overhead. There was minimal (if any) benefit to I/O for data access. Yes lower overhead for that IO, but it was still done. Depending on real storage pressure, it might even have been more I/O for the data than if it were non-VIO. Fast Forward: Larger storage sizes, faster I/O, cached DASD. Physical I/O to FICON DASD is usually < 1ms, and certainly less < 4ms. The relative advantage of VIO is far less. I have seen no significant advantage to VIO in many years (and a few problems with wild allocations). End of history lesson: SYS1.STGINDEX is only used for VIO journaling. If the IPL performed is a CLPA, all VIO journaling is lost. Ergo, why have SYS1.STGINDEX at all? Remember VIO is (supposed to be) only used for small temporary datasets. In my experience they were usually emulated by a small capacity device to limit the max amount of data that could be stored a particular VIO dataset. This tended to minimize the problems with paging and "wild allocations". HTH, ---------------------------------------------------------------------- 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
