Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     FOC$HOLD in multi-user environment

Read-Only Read-Only Topic
Go
Search
Notify
Tools
FOC$HOLD in multi-user environment
 Login/Join
 
<Craig>
posted
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!
 
Report This Post
Tred
Silver Member
posted Hide Post
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.
 
Posts: 37 | Registered: April 14, 2003Report This Post
EricH
Platinum Member
posted Hide Post
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
 
Posts: 164 | Registered: March 26, 2003Report This Post
Carol Dobson
Guru
posted Hide Post
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
 
Posts: 428 | Location: Springfield, MA | Registered: May 07, 2003Report This Post
susannah
Expert
posted Hide Post
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.
 
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003Report This Post
<toby mills>
posted
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
 
Report This Post
<Craig>
posted
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.
 
Report This Post
susannah
Expert
posted Hide Post
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.
 
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003Report This Post
<toby mills>
posted
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
 
Report This Post
Spence
Platinum Member
posted Hide Post
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
 
Posts: 189 | Location: pgh pa | Registered: October 06, 2004Report This Post
Tony A
Expert
posted Hide Post
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.
 
Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     FOC$HOLD in multi-user environment

Copyright © 1996-2020 Information Builders