We rope all true temporary data sets under MAXSIZE into VIO and it works
very well. I just ran into one bizarre case we had to provide an
exception for by DATACLAS.
BMC has a utility that uses temporary data sets between MVS address
spaces. Just a consideration when you set things up eventually you
will have to make an exception plan for it when you put it in.
*BMC180502C THE TEMPORARY DATA SET ALLOCATED TO DD 'SYS00118' CANNOT BE
ON.VIO.
--------------------------------------- V=BMC P=BKUP&RCVY SOLUTN IMS
R=V1R3 I=BMC180502C -
**************** Text below copyright 2004 BMC Software, Inc.
****************
BMC180502C THE TEMPORARY DATA SET ALLOCATED TO DD "ddname" CANNOT BE ON
VIO
Explanation: When you specify the SIUSORT keyword, Index Build function
shares
temporary data sets between related address spaces. Virtual I/O (VIO)
data
sets cannot be used with SIUSORT because they are accessible only from
the
creating address space.
System Action: The job step terminates.
User Response: The TEMPUNIT and SMS keywords in the environment setup
member
(DLIGSET0) determine the allocation of temporary data sets. Ensure that
these
keywords point to non-VIO units. See the CONCURRENT REORG and the
Extended
Performance Utilities Reference Manual for more information.
****************************** BOTTOM OF DATA
********************************
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Skip Robinson
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]
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
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
