(This reply is little out of date, but it needs to be said.)
I've snipped everything because I don't want to call out anyone in
particular. Every response I saw missed a crucial justification for
limiting XMIT/RECEIVE data. It's not about spool saturation, although that
could be a problem. Nor about NJE saturation, although that could also be a
problem. Here's the real problem:
VIO(xxxxxx) Device type on which temporary space can be allocated
for use by the TRANSMIT and RECEIVE commands
Use of VIO for XMIT may seem unmotivated, but the latest Init&Tuning
Reference still recommends it:
Note: IBM recommends that unitname be a device type that you designated as
VIO at IPL. The use of VIO ensures the integrity of sensitive data.
Performance is not the reason for VIO. If you put data on spool, it can be
seen by a random band of other users. VIO is secure. Thousands or even
millions of lines these days in spool or on NJE probably don't matter
nearly as much as they did 20 years ago, but VIO is still virtual memory,
and it's still a finite resource.
I once nearly lost a system because XMIT went to VIO as recommended, and
someone XMITted a really large file. I was able to cancel the user before
the system rolled over on its side, but the effect was not pretty. Of
course not using VIO negates this concern, but you're back to putting file
data in a place where SAF probably has a lot less precision in most shops
than it does for data sets.
Sometimes old fashioned restrictions stem from valid concerns.
.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
<snip all>
----------------------------------------------------------------------
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
