1. Forum
  2. Usenet
  3. COMP.SYS.TANDEM

  • Temporary files not automatically deleted

    From Keith@21:1/5 to All on Wed Nov 1 22:47:14 2023
    DSAP shows a large amount of temp files on a disk. On closer investigation I found out that there are lots of temp files but are not opened by any processes. This should not happened as closing a temp file should have it automatically deleted. Attempt to
    manually purge them returns an error 12. Has anyone encountered this and how to fix this?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JShepherd@21:1/5 to All on Thu Nov 2 13:59:21 2023
    In article <[email protected]>, [email protected] says...

    DSAP shows a large amount of temp files on a disk. On closer investigation = >I found out that there are lots of temp files but are not opened by any pro= >cesses. This should not happened as closing a temp file should have it auto= >matically deleted. Attempt to manually purge them returns an error 12. Has = >anyone encountered this and how to fix this?



    A bigger problem, on systems with a lot of SQL/MX create/drop happening,
    is the mass of .ddl files in /usr/tandem/sqlmx/ddl .

    A single QA test cycle on MX here can create/drop a thousand MX tables.

    The first time /usr became full it took a while to find the culprit,
    which was was over 300,000 .ddl files in /usr/tandem/sqlmx/ddl

    Now, we have a program we run occasionally to clean them out

    From this morning on one system
    mxscan has deleted 14068 .ddl files

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to JShepherd on Thu Nov 2 15:03:54 2023
    On Thursday, November 2, 2023 at 9:59:24 a.m. UTC-4, JShepherd wrote:
    In article <[email protected]>,
    [email protected] says...

    DSAP shows a large amount of temp files on a disk. On closer investigation =
    I found out that there are lots of temp files but are not opened by any pro=
    cesses. This should not happened as closing a temp file should have it auto=
    matically deleted. Attempt to manually purge them returns an error 12. Has = >anyone encountered this and how to fix this?
    A bigger problem, on systems with a lot of SQL/MX create/drop happening,
    is the mass of .ddl files in /usr/tandem/sqlmx/ddl .

    A single QA test cycle on MX here can create/drop a thousand MX tables.

    The first time /usr became full it took a while to find the culprit,
    which was was over 300,000 .ddl files in /usr/tandem/sqlmx/ddl

    Now, we have a program we run occasionally to clean them out

    From this morning on one system
    mxscan has deleted 14068 .ddl files

    You might want to look at how swap space is configured on your system. Some of these files (particularly the ones you cannot purge) might be associated with those.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith@21:1/5 to JShepherd on Sun Nov 5 16:59:13 2023
    On Friday, November 3, 2023 at 12:59:24 AM UTC+11, JShepherd wrote:

    DSAP shows a large amount of temp files on a disk. On closer investigation =
    I found out that there are lots of temp files but are not opened by any pro=
    cesses. This should not happened as closing a temp file should have it auto=
    matically deleted. Attempt to manually purge them returns an error 12. Has = >anyone encountered this and how to fix this?
    A bigger problem, on systems with a lot of SQL/MX create/drop happening,
    is the mass of .ddl files in /usr/tandem/sqlmx/ddl .

    A single QA test cycle on MX here can create/drop a thousand MX tables.

    The first time /usr became full it took a while to find the culprit,
    which was was over 300,000 .ddl files in /usr/tandem/sqlmx/ddl

    Now, we have a program we run occasionally to clean them out

    From this morning on one system
    mxscan has deleted 14068 .ddl files


    Raised this with HPE. The issue was that a permanent file with CLEARONPURGE was purged. DP2 converts this to a temp file but did not purge it. It's a DP2 issue unfortunately.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)