[...good leading discussion snipped...]

As Ron mentioned, MPE/iX will get "cranky" as it runs out of transient
space (or <long-name> volume set space in general), shutting spool
queues, refusing additional logons, etc.; but it takes some real
persistant trouble to crash it.

As to the VOLUTIL perm/trans issue of 75/75, 100/100, or whatever your
choice, there are some "undocumented" features at play here which you
can only discover by trial by fire, so to speak.  (Anyone seen my
soapbox?  Ahhh, there it is...)

(1) For user volumes, transient space is a moot point (no transient
space is ever allocated on a user volume).

(2) Permanent+Transient allocation must be >= 100.  You can't "reserve"
any space to act as a buffer when you're running tight on space.

(3) Regardless of your ldev 1 allocations, as of MPE/iX 5.0 the system
will not allocate more than 50% of available space provided space is
available on another <long-name> volume.

For user volumes, setting 100/0 is typical; setting permanent to
anything less than 100 can however be used to provide a buffer (do you
want to run out of space with no immediate fix, or run out of space and
fix it with a quick volutil command?).  You can use 95/5 (or similar)
allocation to provide a buffer against exhausting your disc space
catastrophically.

For system volumes, however, you can't do this by rule (2) above, so as
you run low on space the volumes of <long-name> other than ldev 1 will
fill to capacity due to rule (3).

This is typically not a problem with MPE applications, but if you are
running any Posix applications, particularly those using fork() (and
that includes the shell itself), you can run into a long-known but
outstanding bug (up through 5.5) that will cause fork() to fail with an
error (resource busy, try again).  fork() clones the parent's stack on
the same ldev and must have contiguous space.

Back to the original 4Gb disc issue -- bear in mind if you put one on
ldev 1, you're wasting 2Gb off the bat.

Jeff Kell <[log in to unmask]>