<?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: f$file_attributes failure in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780496#M41540</link>
    <description>Yeah, F$FILE uses SYS$OPEN and thus requires sharing access, as it allows data access.&lt;BR /&gt;&lt;BR /&gt;DIRECTORY (/FULL) uses ACP QIOS just for the attributes.&lt;BR /&gt;&lt;BR /&gt;I consider it a DCL bug to have implemented it this way, but what are we to do?&lt;BR /&gt;It should also allow for a list of attributes IMHO, to avoid excessive work, but again that's not how it is.&lt;BR /&gt;&lt;BR /&gt;So for myself I wrote a little C program (attached!) to mimiv F$FILE, but use an ACP QIO to get attributes. Of course is is not integrated as nicely as F$FILE, and is involves an image activation, but it has helped me out!&lt;BR /&gt;&lt;BR /&gt;Code attached, and sample usage below.&lt;BR /&gt;Enjoy!&lt;BR /&gt;&lt;BR /&gt;Hein&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com&lt;BR /&gt;Usage: $ mcr f$file &lt;FILE_NAME&gt; "[PRINT,]CDT, EOF, ..." [comment]&lt;BR /&gt;Defines F_FILE&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com ebk,ffb,org&lt;BR /&gt;F$FILE -- unsupported attribute &lt;EBK&gt; requested. Returning &lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com eof,ffb,org&lt;BR /&gt;$ show sym *file*&lt;BR /&gt;  F_FILE = "4|280|SEQ"&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com print,rat,rfm&lt;BR /&gt;CR|VAR&lt;BR /&gt;&lt;/EBK&gt;&lt;/FILE_NAME&gt;</description>
    <pubDate>Fri, 22 Apr 2011 17:26:13 GMT</pubDate>
    <dc:creator>Hein van den Heuvel</dc:creator>
    <dc:date>2011-04-22T17:26:13Z</dc:date>
    <item>
      <title>f$file_attributes failure</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780495#M41539</link>
      <description>Is there a way around this?  A directory command works but is harder to parse.&lt;BR /&gt;&lt;BR /&gt;$!&lt;BR /&gt;$! Get the creation date and size.&lt;BR /&gt;$!&lt;BR /&gt;$ filetime = f$file_attributes(filename, "CDT")&lt;BR /&gt;%SYSTEM-W-ACCONFLICT, file access conflict&lt;BR /&gt; \PPR$DISK:[PPR.PPR_COMMON.HISTORY]TI_HIST_REPORT.201104221329;1\&lt;BR /&gt;$ filesize = f$file_attributes(filename, "EOF")&lt;BR /&gt;%SYSTEM-W-ACCONFLICT, file access conflict&lt;BR /&gt; \PPR$DISK:[PPR.PPR_COMMON.HISTORY]TI_HIST_REPORT.201104221329;1\&lt;BR /&gt;$ if filesize .le. 0 then goto file_loop          &lt;BR /&gt;</description>
      <pubDate>Fri, 22 Apr 2011 16:55:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780495#M41539</guid>
      <dc:creator>Shael Richmond</dc:creator>
      <dc:date>2011-04-22T16:55:26Z</dc:date>
    </item>
    <item>
      <title>Re: f$file_attributes failure</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780496#M41540</link>
      <description>Yeah, F$FILE uses SYS$OPEN and thus requires sharing access, as it allows data access.&lt;BR /&gt;&lt;BR /&gt;DIRECTORY (/FULL) uses ACP QIOS just for the attributes.&lt;BR /&gt;&lt;BR /&gt;I consider it a DCL bug to have implemented it this way, but what are we to do?&lt;BR /&gt;It should also allow for a list of attributes IMHO, to avoid excessive work, but again that's not how it is.&lt;BR /&gt;&lt;BR /&gt;So for myself I wrote a little C program (attached!) to mimiv F$FILE, but use an ACP QIO to get attributes. Of course is is not integrated as nicely as F$FILE, and is involves an image activation, but it has helped me out!&lt;BR /&gt;&lt;BR /&gt;Code attached, and sample usage below.&lt;BR /&gt;Enjoy!&lt;BR /&gt;&lt;BR /&gt;Hein&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com&lt;BR /&gt;Usage: $ mcr f$file &lt;FILE_NAME&gt; "[PRINT,]CDT, EOF, ..." [comment]&lt;BR /&gt;Defines F_FILE&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com ebk,ffb,org&lt;BR /&gt;F$FILE -- unsupported attribute &lt;EBK&gt; requested. Returning &lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com eof,ffb,org&lt;BR /&gt;$ show sym *file*&lt;BR /&gt;  F_FILE = "4|280|SEQ"&lt;BR /&gt;$ mcr sys$login:f$file sys$login:login.com print,rat,rfm&lt;BR /&gt;CR|VAR&lt;BR /&gt;&lt;/EBK&gt;&lt;/FILE_NAME&gt;</description>
      <pubDate>Fri, 22 Apr 2011 17:26:13 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780496#M41540</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2011-04-22T17:26:13Z</dc:date>
    </item>
    <item>
      <title>Re: f$file_attributes failure</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780497#M41541</link>
      <description>Btw... if this happens a lot, then you may want to protect your F$FILE with an OPEN first&lt;BR /&gt;&lt;BR /&gt;$OPEN/error=probably_locked/SHARE=WRITE file 'filename&lt;BR /&gt;$filetime = f$file_attributes(filename, "CDT")&lt;BR /&gt;:&lt;BR /&gt;$CLOSE file&lt;BR /&gt;:&lt;BR /&gt;$probably_locked:&lt;BR /&gt;$ status = $STATUS&lt;BR /&gt;$ IF status .EQ. %x0800&lt;BR /&gt;$ THEN...&lt;BR /&gt;:&lt;BR /&gt;&lt;BR /&gt;fwiw,&lt;BR /&gt;&lt;BR /&gt;Hein.</description>
      <pubDate>Fri, 22 Apr 2011 17:36:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/f-file-attributes-failure/m-p/4780497#M41541</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2011-04-22T17:36:08Z</dc:date>
    </item>
  </channel>
</rss>

