Dear friends,

Back on Tue, 21 Oct 1997 13:06:12 GMT, Mark Landin commented on what I said:
>>>It might be worthwhile to migrate the developers to their own volume set,
>>>where they will get the chance to learn more intimately about the
>>>consequences
>>>of filling up available disk space.
with Mark observing:
>>While this is a good practice in general (in fact, putting the developers
on
>>their own *machine* is even better), all transient space is contained in
the
>>MPEXL_SYSTEM_VOLUME_SET; in this case the problem of giant temp files
>>exhausting system volume space would remain regardless of whatever user
>>volumes might be used.

Well, yes and no (or not necessarily):
Yes:>> all transient space is contained in the MPEXL_SYSTEM_VOLUME_SET...
No:>> giant temp files exhausting system volume space...

Please refer to the later part of my original posting:
>TEMP files (files in the temporary domain) are built in "Permanent space",
the
>same as permanent disk files, and can reside on non-system volume sets.
>Transient space is for objects such as swapped memory pages; it can only be
>configured on the system volume set...

If the developers are restricted to their own volume set, all of their
permanent and temporary files will be restricted to that volume set.
Granted,
if said developers write code that grabs lots of virtual memory (or run lots
of recursive Posix fork() calls that grab lots of virtual memory) then they
still may potentially tie up transient space on the MPEXL_SYSTEM_VOLUME_SET.

Mark Hocraffer (who started the thread), Mark Landin and I do seem to come
to
the same conclusion: keep the developers off the production system, at least
during production hours.

Thanks,
Scott (spending a pleasant evening catching up on the Digest) Burdman
Midrange Team - Americas
Oracle Worldwide Customer Support Services
{insert standard disclaimer here}