For reasons I won't go into, we MUST use a temporary directory to store our hold files (APP HOLD dir). We are trying to find out if HOLD FORMAT FOCUS, which creates the temporary FOC$HOLD file (the TABLEd out and MODIFYed in file) might be a concern when 2 or more users create these FOCUS files at the same time? We could play around with the APP HOLD command before and after the creation, but I'm wondering if anyone else has run into this before and how they solved it. On a more basic level, does anyone know if theses FOC$HOLD files are uniquely identified by process with WF? Or does the potential exist to "clobber" files? We are not doing any more than 1500 line creations, so this file is not there long, nevertheless, the client is concerned.

Thanks!

Craig,

This will cause issues if each user is HOLDing into the exact same directory. If its feasible for your process, have a unique directory for each user that can be controlled by an amper variable, so the APP HOLD command can dynamically separate instances, i.e. APP HOLD &DIRNAME where &DIRNAME is the user's id (providing there is a directory that user can write to, named after their userid). - If this process absolutely has to write to the same temp directory regardless of who is running it, you will have clashing issues.

Craig,

You may also want to delete each user's temp directory at the end of the job/session. Otherwise, the next time a user runs a job, the temporary files from the previous run will still be there. Depending on the nature of what you're doing, this could mess up successive runs.

EricH

Hi Craig,
Hope all is well!
The easiest way is to SET TEMPERASE = ON for the FOC$HOLD creation then set it back off after the temporary file has been created along with the APP HOLD command.

Good Luck,
Carol

Craig, i applaud all who have answered so far...
but now i'm curious...what IS the reason you wont go into?
Each 'fexecution' runs in its own 'temp directory', aka 'agent'. when the execution is finished, the stuff in the temp directory evaporates...well, most of the time. Unless there's a screwup or, as Carol says, you've deliberatly told it not to dump by setting TEMPERASE off. But the point is, they're separate directories...no conflicts among simultaneous executions.
How are you planning to get Every execution to use the same 'agent directory'? are you going to specify SET TEMPDIR=someCommonPlace? Pretty scary. Everbody will be reading each other's hold files and makeing a big glorious colorful carcrash.

which gives me an idea..Do you by any chance have TEMPDIR already set to something?
That might be the problem. If you have TEMPDIR set to somerealplace, for a given fex, then you'ld be getting foc$holds clobbering each other. TEMPDIR can be dangerous, that way.
Let us know if that's the case, and we'll show you how to unwind it.

I'm curious too about why you don't just let edatemp do it's thing? If it's a case of space, you can point edatemp to a different disk or something....

Fill us in Craig?

-Toby

The problem is persistance.. We need to keep the HOLD files around as users can sort, run sub-extracts, etc WITHOUT having to do a SQL pull each time the process ends. We've tried playing around with TEMPERASE but to no real resolution.

then you might want to let edatemp do its thing, as toby says, but just filedef your keep-able hold files (being sure to NAME them something other than HOLD ) to the user's own directory.
so tempdir gets set to the agent, that means no foc$hold or hold problems.
and keepables get set to the user's own directory, with specific filedefs or use statements.
We old mainframers have learned to let go (albeit kicking and screaming) of the persistence thing by using drilldowns, and clever sorting-option drilldowns in column headers.

Hey Craig

I was wondering if your data all looks the same (column wise - just different rows depending on user selection)?

If so, that makes your life easier.

Commands that I'm thinking of that might be useful to you in your quest:

-* get the temppath that eda is using for edatemp
-* so you can COPY your file from here if you'd -* prefer.
-SET &TPATH = TEMPPATH(80, 'A80');

&IBIMR_user - you might want to use this to rename your hold file or just decide what directory to put his hold files in.

APP MAP - to point to the new holdfile....

Out of the box - if the columns of data is all the same for all the users, how about a single SQL Server table (or focus db) to hold the data for everybody keyed on user id?

Just some ideas...

-Toby

You can create the hold files with a time stamp to keep them unique.

-SET &TIME = &TOD;
-SET &MMSS = EDIT(&TIME,'$$$99$99');
-SET &HF = 'HF'||&MMSS;
-SET &HF1 = &HF||'.FTM';
FILEDEF &HF DISK c:\ibi\apps\tempfile\&HF1
APP HOLD TEMPFILE

TABLE FILE XXX
PRINT XXX
ON TABLE HOLD AS &HF FORMAT ALPHA
END

Craig,

You don't mention the platform you are on but I am assuming Windows?

If you are concerned about the FOC$HOLDs causing problems then just leave EDATEMP to do its thing but perform a DOS COPY at the end of the fex to copy it to the directory of your choice before the TSnnnnnn directory gets erased. Another advantage of this is that a name change can be achieved at the same time.

If you put the whole thing in reuseable code then you can control the method site wide rather than on a proc by proc basis just by including the proc at the end of each report.