Another area to watch out for is TSOE TRANSMIT. In PARMLIB, you specify a unit name for 'VIO'. If 'VIO' points to true VIO--directly via the IODF EDT or via SMS--then you can saturate your paging system pretty quickly if someone XMITs a huge file. On the other hand, you can point 'VIO' to ordinary DASD safely with some loss of performance.
As to the original question, there are really two: (1) Do you need the name VIO in your EDT? (2) Do you need to point 'VIO' to virtual storage? I personally believe that the name is 'mandatory'. So many canned PROCs and installation guides come with UNIT=VIO that it's crazy not to have it. I was in a shop once where someone before me had decided that SYSVIO was a better name. Besides the effort of modifying vendor supplied JCL, there was the hassle of a programmer struggling to get a job to work because she didn't understand the problem. An installation created problem. So for the sake of everyone's sanity, please define VIO in the EDT. If you don't want to take a chance on possible paging problems, then make VIO the same as DISK or SYSDA or whatever common name you have for 'any available work volume'. Or use SMS to allocate VIO to virtual storage based on size. Just don't omit the name altogether. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <[email protected]> wrote on 01/26/2006 11:08:38 PM: > Greg Price wrote: > > Years ago I found directing compiler (PL/I and Assembler) work files to > > VIO could reduce the elapsed time of a compilation to a fraction of what > > it otherwise would be. May not be true now... or systems are so fast it > > doesn't matter much anymore. > > Months ago I found that using VIO for an assembly (XF under turnkey) > that produces a prodigious volume of error messages will crash MVS. As a > result, every one of my PROCs that specifies VIO does so with a > replaceable variable (WORK=). If I assemble a large program I'll use > SYSDA the first try, then switch back. > > Gerhard Postpischil > Bradford, VT ---------------------------------------------------------------------- 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
