In our test environment we haven't installed a Report Caster.

We have a fex like this


-INCLUDE genData.fex
-INCLUDE b.fex
-INCLUDE c.fex
-INCLUDE d.fex


The genData.fex creates the data used in the subsequent fexes.
The subsequent fexes create temporary files using great amout of space. Is there a posibility to delete the temporary tables and free the used space after / in the subsequent fexes?

This message has been edited. Last edited by: Kerry,

In our space hungry fexes, we add OS delete command after the files are finished with.

For you it would be -WINNT del ... or ! del ..., etc.

Sorry for my bad description. The temporary files are not written to disk and not visible by the windows explorer. I think they are hold by FOCUS because the free amount of space grows after the end of the fex from e.g. 5 GB to 8 GB.

If they are hold files, then they are being written somewhere.

Usually this is in the temp directory, and are cleared out when the report finishes.

Do you have APP HOLD commands ?

This would possibly put the files somwhere permanant.

The files must be visible somewhere. Is this on a server or PC ?

There is nothing other then what Waz mentioned to erase temp files while the agent is still running. When the agent finishes its work, it will erase all files from its temp directory, unless otherwise specified by the SET TEMPERASE command.
If you do not specify where to hold files, the agent will hold them in its temp directory, usually in a directory similar to: D:\ibi\srv77\wfs\edatemp\ts000005

You can use the line below to find out where your files are being written in edatemp space:
-SET &TEMPPATH = TEMPPATH(255,'A255');
Then, you can delete the files as your program processes and large files are no longer needed. I'm not sure if you can delete the focsort file since it grows during the process and doesn't release space until the program ends.

I believe that if you reuse the name, you reuse the space. If you have a file that is only going to be used in one step and is then no longer needed do an ON TABLE HOLD without giving it a name. (You then TABLE FILE HOLD). If you have files that are needed later for a join or a match (rather than the next step) you can use names like HOLD1 and HOLD2. If you do that in all of your processes c.fex will write over the files from b.fex.

quote:

reuse the name

This is a potentially dangerous way to use hold files.

e.g.

First Table file produces records to HOLD
Second Table file produces none to HOLD.

If you then table from the HOLD what will be returned ?

Because there are no records, does the hold file get overwritten ?

This was definitely an issue in older versions of WebFOCUS.

There is one other thing that can cause space to be used up.

That is the server logs, or even if tracing has been left on.

Perhaps my recent thread on a similar (same?) subject will help. http://forums.informationbuild...1057331/m/7107069606

My issue is that I am running out of temp space in a few jobs and my admins didn't want to increase my disk allocation, so I had to find a way to clean up after myself along the way.

This link may help too:
http://techsupport.information...om/sps/51112546.html

Also -- there can be a vast difference is record length (hence, overall size) of the hold file, between Holding in readable (Alpha) format vs. internal ("Binary") format. Check it out.

You may also try using APP DELETEF though it may have constraints as to the types of files that can be deleted.

The good thing about it is that it is supported transparently across most platforms where WebFOCUS runs so you won't need to code delete commands particular to your OS. In additions, a few environments may have security constraints where OS commands are restricted so "rm" or "del" would be disallowed; I've never hit that case myself but I think I read it's possible to actually disable them.