<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2 in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878705#M103894</link>
    <description>&lt;P&gt;In this case the error is clear. &amp;nbsp;The disk is full. (allocation failure). &amp;nbsp;&lt;/P&gt;&lt;P&gt;As indicated in previous replies, there are 2 ways to resolve this:&lt;/P&gt;&lt;P&gt;1) Redirect sys$scratch to a device with more space.&lt;/P&gt;&lt;P&gt;2) Redirect sortwork files to other devices.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;One or the other of the above should resolve the problem.&lt;/P&gt;&lt;P&gt;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. &amp;nbsp;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. &amp;nbsp;As before, the volume set will avoid any size limitations of VMS but allow for increased space for the work files.&lt;/P&gt;&lt;P&gt;Dan&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 15 Jul 2016 12:48:18 GMT</pubDate>
    <dc:creator>abrsvc</dc:creator>
    <dc:date>2016-07-15T12:48:18Z</dc:date>
    <item>
      <title>RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878496#M103891</link>
      <description>&lt;P&gt;All,&lt;BR /&gt;We use CharonVAX OpenVMS 6.1, Rdb/VMS v4.1. , The DB files are spread on to 4 disks, each disk is 4GB.&lt;BR /&gt;I had created 3 threads earlier on the same import issue, resolved with other server.&amp;nbsp;&lt;BR /&gt;&lt;FONT color="#000000"&gt;The DB size is more than 8GB, so created larger size vdisk (&amp;gt;8GB), but the backup &amp;amp; export was failing earlier, so created bound volume(8+8GB) and batch update option, it got resolved. &lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;This issue is again with Import, but in the different server, this time the error is different &amp;amp; as below.&lt;/FONT&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;&lt;BR /&gt;Importing table Telar&lt;BR /&gt;Importing table Telcc&lt;BR /&gt;%SQL-F-NOIDXRES, unable to import index telcc_index&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;%RDB-F-SYS_REQUEST, error from system services request&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;-SORT-E-WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;-SYSTEM-W-DEVICEFULL, device full; allocation failure&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT color="#000000"&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2"&gt;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.&lt;BR /&gt;&lt;/FONT&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2"&gt;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?&lt;/FONT&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#000000"&gt;Appreciate your assistance.&lt;BR /&gt;Thanks&lt;BR /&gt;&lt;/FONT&gt;&lt;FONT face="arial,helvetica,sans-serif" size="2" color="#800000"&gt;&lt;FONT color="#000000"&gt;Navipa&amp;nbsp;&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT color="#000000"&gt;&amp;nbsp;&lt;/FONT&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/FONT&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Jul 2016 19:48:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878496#M103891</guid>
      <dc:creator>Navipa</dc:creator>
      <dc:date>2016-07-14T19:48:24Z</dc:date>
    </item>
    <item>
      <title>Re: RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878528#M103892</link>
      <description>&lt;P&gt;&amp;gt; [...] I have a plan of creating larger system disk, will it resolve&lt;BR /&gt;&amp;gt; this issue? or is there any other way?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I know nothing about most of this stuff, but, if RDB and/or SORT is&lt;BR /&gt;using the logical name SYS$SCRATCH as the place to put its temporary&lt;BR /&gt;files, then you might try defining SYS$SCRATCH as some directory on a&lt;BR /&gt;disk which has more free space than your system disk.&lt;/P&gt;&lt;P&gt;&amp;gt; [...]SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; Around here, for user SYSTEM:&lt;/P&gt;&lt;P&gt;ALP $ show logi sys$scratch&lt;BR /&gt;"SYS$SCRATCH" = "SYS$SYSROOT:[SYSMGR]" (LNM$JOB_82BB7F40)&lt;/P&gt;&lt;P&gt;ALP $ show logi sys$login&lt;BR /&gt;"SYS$LOGIN" = "SYS$SYSROOT:[SYSMGR]" (LNM$JOB_82BB7F40)&lt;/P&gt;&lt;P&gt;That is, the usual value for SYS$SCRATCH is the user's SYS$LOGIN.&amp;nbsp; For&lt;BR /&gt;user SYSTEM, that's normally on the system disk.&amp;nbsp; But you can define&lt;BR /&gt;SYS$SCRATCH to whatever you want (where you have write permission).&lt;BR /&gt;Programs which use SYS$SCRATCH will follow your direction.&lt;/P&gt;</description>
      <pubDate>Thu, 14 Jul 2016 21:11:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878528#M103892</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2016-07-14T21:11:47Z</dc:date>
    </item>
    <item>
      <title>Re: RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878531#M103893</link>
      <description>&lt;P&gt;It looks like VMS SORT is involved, which can use several work files on different disks.&amp;nbsp;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.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Jul 2016 21:29:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878531#M103893</guid>
      <dc:creator>H.Becker</dc:creator>
      <dc:date>2016-07-14T21:29:12Z</dc:date>
    </item>
    <item>
      <title>Re: RMU Import fails with WRITEERR, error writing SYS$SYSROOT:[SYSMGR]SORTWORK1.TMP;2</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878705#M103894</link>
      <description>&lt;P&gt;In this case the error is clear. &amp;nbsp;The disk is full. (allocation failure). &amp;nbsp;&lt;/P&gt;&lt;P&gt;As indicated in previous replies, there are 2 ways to resolve this:&lt;/P&gt;&lt;P&gt;1) Redirect sys$scratch to a device with more space.&lt;/P&gt;&lt;P&gt;2) Redirect sortwork files to other devices.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;One or the other of the above should resolve the problem.&lt;/P&gt;&lt;P&gt;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. &amp;nbsp;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. &amp;nbsp;As before, the volume set will avoid any size limitations of VMS but allow for increased space for the work files.&lt;/P&gt;&lt;P&gt;Dan&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 15 Jul 2016 12:48:18 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/rmu-import-fails-with-writeerr-error-writing-sys-sysroot-sysmgr/m-p/6878705#M103894</guid>
      <dc:creator>abrsvc</dc:creator>
      <dc:date>2016-07-15T12:48:18Z</dc:date>
    </item>
  </channel>
</rss>

