<?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: The Sort Utility and available diskspace in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608783#M7488</link>
    <description>Dom,&lt;BR /&gt;&lt;BR /&gt;  As Hein has pointed out, it takes a seriously bad event to break SORT. Just check the stats.&lt;BR /&gt;&lt;BR /&gt;  There are techniques for creating sort work areas that permit sortwork files to bypass disk quotas.</description>
    <pubDate>Mon, 22 Aug 2005 17:30:30 GMT</pubDate>
    <dc:creator>John Gillings</dc:creator>
    <dc:date>2005-08-22T17:30:30Z</dc:date>
    <item>
      <title>The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608777#M7482</link>
      <description>When I sort a very big file, the sort utility uses the SortworkN disks but always uses the smallest disk first.  This means I always get the following messages:&lt;BR /&gt;&lt;BR /&gt;%SORT-E-WRITEERR, error writing _HSD10$DIA140:[PATENTS]SORTWORK.TMP;&lt;BR /&gt;-SYSTEM-F-EXDISKQUOTA, disk quota exceeded&lt;BR /&gt;&lt;BR /&gt;We're of two minds here.  Some of us say that this "E" error for sort and the "F" error from system are handled by the Sort Utility, so that it just goes to the next SortworkN disk.  Proof of this is that Sort does not just die, but continues on and reports its statistics correctly.  &lt;BR /&gt;&lt;BR /&gt;Others say it is an "E" and "F" error, and therefore the results of the sort are not correct.&lt;BR /&gt;&lt;BR /&gt;Any ideas?&lt;BR /&gt;&lt;BR /&gt;Dom&lt;BR /&gt;</description>
      <pubDate>Mon, 22 Aug 2005 11:18:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608777#M7482</guid>
      <dc:creator>Dominic Olivastro</dc:creator>
      <dc:date>2005-08-22T11:18:37Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608778#M7483</link>
      <description>&lt;BR /&gt;&amp;gt;&amp;gt; Some of us say that this "E" error for sort and the "F" error from system are handled by the Sort Utility.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Agreed. This can happen with diskspace and also virtual memory (where sort switches to disk earlier then it intended).&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt; ;&lt;BR /&gt;-SYSTEM-F-EXDISKQUOTA, disk quota exceeded&lt;BR /&gt;&lt;BR /&gt;Quota exceeded is kind of a silly reason to run into trouble isn't it? Or is this just meant as an example and are you mostly concerned about really running out of actual disk space.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Hein.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 22 Aug 2005 11:46:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608778#M7483</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2005-08-22T11:46:57Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608779#M7484</link>
      <description>Dominic,&lt;BR /&gt;HELP /MES WRITEERR WRITEERR&lt;BR /&gt; WRITEERR,  error writing 'file-spec'&lt;BR /&gt;&lt;BR /&gt;  Facility:     Shared by several facilities&lt;BR /&gt;&lt;BR /&gt;  Explanation:  During an OpenVMS RMS file system operation, an error is&lt;BR /&gt;                encountered while writing a file.&lt;BR /&gt;&lt;BR /&gt;                If this error occurred during a macro assembly operation,&lt;BR /&gt;                the assembler encountered an I/O error when writing to the&lt;BR /&gt;                output object module or listing file; 'file-spec' is the file&lt;BR /&gt;                specification of the file being written.&lt;BR /&gt;&lt;BR /&gt;  User Action:  Determine that the file is open and that you have write&lt;BR /&gt;                access. If this is a macro assembly error, retry the assembly.&lt;BR /&gt;                If the error is reproducible, notify your system manager.&lt;BR /&gt; &lt;BR /&gt;I think your sorted file is not correct. However I don't risk lost data :-!&lt;BR /&gt; &lt;BR /&gt;Antonio Vigliotti&lt;BR /&gt;</description>
      <pubDate>Mon, 22 Aug 2005 11:53:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608779#M7484</guid>
      <dc:creator>Antoniov.</dc:creator>
      <dc:date>2005-08-22T11:53:11Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608780#M7485</link>
      <description>Hein -- Just an example.  My major concern is this:  Can I trust the output of the sort.  I think that the error messages are being handled within the sort, and it corrects the error just by moving to the next sortworkn disk.  I base this on the fact that SORT continues from this error, and gives me a $Status showing success.&lt;BR /&gt;&lt;BR /&gt;Antoniov -- I'm aware of the explanation, but the question remains, "Is sort handling this error?  If not, why does it not just crash?"&lt;BR /&gt;&lt;BR /&gt;Thanks to both of you guys.&lt;BR /&gt;&lt;BR /&gt;Dom</description>
      <pubDate>Mon, 22 Aug 2005 12:32:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608780#M7485</guid>
      <dc:creator>Dominic Olivastro</dc:creator>
      <dc:date>2005-08-22T12:32:53Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608781#M7486</link>
      <description>Sort is handling the eror.&lt;BR /&gt;&lt;BR /&gt;Use /STAT to confirm that there were as many input records as output records.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;I'll include a most exquisite answer from an orginal sort engineer from our archives:&lt;BR /&gt;&lt;BR /&gt;Hien.&lt;BR /&gt;&lt;BR /&gt;----------------------------------------&lt;BR /&gt;Note 24.10  Strange SORT behaviour&lt;BR /&gt;CLT::GILBERT "Multiple inheritence  happens" 4-OCT-1988&lt;BR /&gt;----------------------------------------&lt;BR /&gt;&lt;BR /&gt;&amp;gt;   We will consider down grading the error message to warning.&lt;BR /&gt;&lt;BR /&gt;    Thanks.  I'm guilty of rampant conservatism for making it E-level in the first place.  The code that diagnoses this problem *does* continue gracefully, and *does* produce correct results; so an I-level diagnostic seems most appropriate -- strangely enough!&lt;BR /&gt;&lt;BR /&gt;%SORT-I-WRITEERR,  Error writing to your scratch file&lt;BR /&gt;-SYSTEM-F-HEADCRASH,  Head crash on disk&lt;BR /&gt;-SYSTEM-F-SMITHEREENS,  Disk exploded and caught on fire&lt;BR /&gt;%SORT-S-TIMEX,  But VAX Sort/Merge takes a licking and keeps on ticking!</description>
      <pubDate>Mon, 22 Aug 2005 13:35:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608781#M7486</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2005-08-22T13:35:36Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608782#M7487</link>
      <description>Thanks so much, Hein.  This is a huge relief for me.  For a long time, people have been arguing that the results of the sort are invalid.  &lt;BR /&gt;&lt;BR /&gt;And I always include a "/Stat" qualifier, and I always check the $Status symbol.&lt;BR /&gt;&lt;BR /&gt;Thanks again,&lt;BR /&gt;Dom&lt;BR /&gt;</description>
      <pubDate>Mon, 22 Aug 2005 13:54:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608782#M7487</guid>
      <dc:creator>Dominic Olivastro</dc:creator>
      <dc:date>2005-08-22T13:54:12Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608783#M7488</link>
      <description>Dom,&lt;BR /&gt;&lt;BR /&gt;  As Hein has pointed out, it takes a seriously bad event to break SORT. Just check the stats.&lt;BR /&gt;&lt;BR /&gt;  There are techniques for creating sort work areas that permit sortwork files to bypass disk quotas.</description>
      <pubDate>Mon, 22 Aug 2005 17:30:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608783#M7488</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2005-08-22T17:30:30Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608784#M7489</link>
      <description>" There are techniques for creating sort work areas that permit sortwork files to bypass disk quotas."&lt;BR /&gt;&lt;BR /&gt;That's interesting.  Can you give me some hints?&lt;BR /&gt;&lt;BR /&gt;Dom&lt;BR /&gt;</description>
      <pubDate>Mon, 22 Aug 2005 17:51:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608784#M7489</guid>
      <dc:creator>Dominic Olivastro</dc:creator>
      <dc:date>2005-08-22T17:51:07Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608785#M7490</link>
      <description>&amp;gt;Can you give me some hints?&lt;BR /&gt;&lt;BR /&gt;  Sure, In the Guide to OpenVMS Security manual you'll find a cookbook example of a "project directory". This is a directory owned by a resource identifier, with access control lists and identifier's granted to allow authrized users to create files in that directory. The files will be owned by the identifier, and therefore subject to the identifier's quota, rather than the quota of the creator.&lt;BR /&gt;&lt;BR /&gt;  One thing to be a bit wary of is to make sure each user specifies unique file names for their SORTWORK files (especially concurrent users). Otherwise theycan tread on each others toes. If you're running a late enough version use F$UNIQUE()&lt;BR /&gt;&lt;BR /&gt;$ DEFINE SORTWORK1 PROJDIR1:'F$UNIQUE()&lt;BR /&gt;$ DEFINE SORTWORK2 PROJDIR2:'F$UNIQUE()&lt;BR /&gt;&lt;BR /&gt;etc...&lt;BR /&gt;&lt;BR /&gt;  The only issue here is users can create other files in the same directory, and consume any extended quota. Simple way around that is to regularly delete anything not currently open.&lt;BR /&gt;&lt;BR /&gt;  A possible alternative which might be more bullet proof (but I've never tested), you could install SORT32 as a protected subsystem image. Work areas could be setup to only be writeable from the SORT32 image. &lt;BR /&gt;&lt;BR /&gt;  See the Guide to OpenVMS System Security for details on protected subsystems - they're an incredibly powerful, but little used feature of OpenVMS. In effect they allow you to bind a set of objects to a specific set of images. For example, some data files that can only be read or written from certain applications.</description>
      <pubDate>Mon, 22 Aug 2005 22:51:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608785#M7490</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2005-08-22T22:51:22Z</dc:date>
    </item>
    <item>
      <title>Re: The Sort Utility and available diskspace</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608786#M7491</link>
      <description>Dominic,&lt;BR /&gt;as other thread I report same link&lt;BR /&gt;&lt;A href="http://h71000.www7.hp.com/doc/731FINAL/6489/6489pro_023.html" target="_blank"&gt;http://h71000.www7.hp.com/doc/731FINAL/6489/6489pro_023.html&lt;/A&gt;&lt;BR /&gt;where you can see some hints about sort.&lt;BR /&gt; &lt;BR /&gt;Antonio Vigliotti&lt;BR /&gt;</description>
      <pubDate>Tue, 23 Aug 2005 02:15:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/the-sort-utility-and-available-diskspace/m-p/3608786#M7491</guid>
      <dc:creator>Antoniov.</dc:creator>
      <dc:date>2005-08-23T02:15:44Z</dc:date>
    </item>
  </channel>
</rss>

