In a recent note, Skip Robinson said: > Date: Tue, 17 May 2005 17:34:03 -0700 > > 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 > VIO at IPL. The use of VIO ensures the integrity of sensitive data. > > 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. > Same rebuttal as the concerns of spool saturation and NJE saturation. If there's a hazard of saturating a resource, protect the resource itself; don't restrict a particular command that exploits the resource.
I once pretty much rolled a system over on its side by inadvertently abusing VIO. I didn't use TRANSMIT to do it, and the limit on TRANSMIT provided no protection. > Sometimes old fashioned restrictions stem from valid concerns. > The concern is perhaps valid; the reaction is incorrect. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
