RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2

[Navipa]

All,
We use CharonVAX OpenVMS 6.1, Rdb/VMS v4.1. , The DB files are spread on to 4 disks, each disk is 4GB.
I had created 3 threads earlier on the same import issue, resolved with other server. 
The DB size is more than 8GB, so created larger size vdisk (>8GB), but the backup & export was failing earlier, so created bound volume(8+8GB) and batch update option, it got resolved.

This issue is again with Import, but in the different server, this time the error is different & as below.
Importing table Telar
Importing table Telcc
%SQL-F-NOIDXRES, unable to import index telcc_index
%RDB-F-SYS_REQUEST, error from system services request
-SORT-E-WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2
-SYSTEM-W-DEVICEFULL, device full; allocation failure

I observe this procedure during its execution, it was Importing the tables normally, but it stuck for long time when it was Importing one of the huge table (telcc), after few minutes, it ($show dev d) suddenly started consuming System-disk space very faslty, and when the system disk free space become less, it failed with above errors.
Is SORTWORK file created all the time?, or does it get created only due to some problem with Importing larger table ? I have a plan of creating larger system disk, will it resolve this issue? or is there any other way?

Appreciate your assistance.
Thanks
Navipa 
 

[Steven Schweda]

> [...] I have a plan of creating larger system disk, will it resolve
> this issue? or is there any other way?

   I know nothing about most of this stuff, but, if RDB and/or SORT is
using the logical name SYS$SCRATCH as the place to put its temporary
files, then you might try defining SYS$SCRATCH as some directory on a
disk which has more free space than your system disk.

> [...]SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2

   Around here, for user SYSTEM:

ALP $ show logi sys$scratch
"SYS$SCRATCH" = "SYS$SYSROOT:[SYSMGR]" (LNM$JOB_82BB7F40)

ALP $ show logi sys$login
"SYS$LOGIN" = "SYS$SYSROOT:[SYSMGR]" (LNM$JOB_82BB7F40)

That is, the usual value for SYS$SCRATCH is the user's SYS$LOGIN.  For
user SYSTEM, that's normally on the system disk.  But you can define
SYS$SCRATCH to whatever you want (where you have write permission).
Programs which use SYS$SCRATCH will follow your direction.

[H.Becker]

It looks like VMS SORT is involved, which can use several work files on different disks. There is very likely some Rdb documentation how to make use of this feature. Dunno whether specifying logicals like SORTWORKn (n=0, 1, ...) is sufficient or whether you need an RDB$something logical, here. So if you have space on other disks, you can use that feature and that may be enough for the Rdb import. 

[abrsvc]

In this case the error is clear.  The disk is full. (allocation failure).  

As indicated in previous replies, there are 2 ways to resolve this:

1) Redirect sys$scratch to a device with more space.

2) Redirect sortwork files to other devices.

Depending upon the size requirements for the sort work files, you may need to use the individual sortwork logicals to utilize more than one disk.

One or the other of the above should resolve the problem.

If you have the ability to add more disks to the system easily, I would create a volume set and direct sys$scratch to it.  The large size will allow for multiple sort work files to reside at sys$Scratch and you won't need to spread the files around.  As before, the volume set will avoid any size limitations of VMS but allow for increased space for the work files.

Dan