Hi
We have an issue with scheduling reports using Report Caster (RC). When we run the same report individually using Dev Studio, it takes the default (current folder) to look for the MFDs. However when we schedule the same report using RC, it looks into some other folder (typically the first encountered alphabetically) and picks up the MFDs from that folder. The problem is that we have the MFDs with the same name in several folders and we wanted to execute the report from a specific folder using RC.
FYI we have also tried to rename the .fex file for the different folders, but this doesnt help.
Also, due to some logic which we are using in the code, we do not want to have APP PATH in our code.
Is there a way how we can instruct the RC to point to the MFDs in the relevant folder?
Any pointers would be helpful.

Regards
Syed

Using WF 7.1.7/Dev Studio

Can you put APP PREPENDPATH in your code instead?

Does the PREPENDPATH work the same way as the APP PATH works?
Can you please let me know how does this work?

Syed

PREPENDPATH put the directory specified in front of the ones in the apppath. So for instance, if you had an apppath of

ibisamp ibidemo prodmas1 prodmas2 prodmas3

and your master was in prodmas2 but you had a master with the same name in prodmas1, you could say

APP PREPENDPATH prodmas2

Then your path would look like this:

prodmas2 ibisamp ibidemo prodmas1 prodmas2 prodmas3

I hope that is clear.

You also need to realize that the user who runs things in DevStudio may or may no be the one who runs the sceduled jobs in RC. The RC user could be looking at an entirely different path than the DevStudio user. This is one of the things you need to be careful of when you create different MFDs with the same name - you may be getting the wrong one depending on who the user is or how it's being run. (RC, server console, DevStudio, etc.)

You could also use user profiles containing the APPPATH, APP APPENDPATH or APP PREPENDPATH - no need to put anything in the code. This allows the RC user to have its own assigned path.

Gotcha
But event if I use APP PREPENDPATH prodmas2, the WebFOCUS will still try to find the intermediate hold files in prodmas2 when referred in the code.
My situation is something like this.
APP PATH abc
TABLE FILE XYZ
PRINT Q P
ON TABLE HOLD AS TST FORMAT ALPHA
END

TABLE FILE TST
....

The ON TABLE HOLD AS TST stores the data in a hold file within a temporary folder created by WebFOCUS (since I have not used APP HOLD). However, when I query TST later on in the code, it is somehow referring to abc folder since I have specified APP PATH.
Is it possible to avoid giving APP PATH or APP PREPENDPATH and give WebFOCUS the flexibility to create intermediate hold files in temp folders? When I do this (by not using APP PATH), the RC doesnt understand where it should pick the MFDs from.
Hope this makes some sense.

Syed

Use APP FI or FILEDEF to specifically specify where you want them to go.

APP HOLD will also work in this scenario.

But if you don't use APP HOLD, the hold files will go into EDATEMP and that is where they will be picked up UNLESS you have like named masters in your application path. You might want to remove the hold files from your application path.

Syed, I am not trying to be critical, but it seems you are doing a lot of work you don't need to and may need to rethink how your environment is set up.

In our environment, we have one reporting server for development and production. As a result, the APP path that is set up on the reporting server is the production job APP Path. When I write code I setup two starting points, one for production and one for testing/devel. Here's a snipet of code:

-SET &RUNTYPE=PROD;
-*
-IF &RUNTYPE NE PROD THEN GOTO SETUP.TEST;
-*
-*  Production Environment
-*
-SET &CLIENT_TST1='-*';
-SET &CLIENT_TST2='-*';
-SET &CLIENT_TST3='-*';
-SET &CLIENT_TST4='-*';
-SET &CLIENT_TST5='-*';
-SET &TMPDIR=' ';
-SET &RUNDTFL='afcrundt.ftm';
-INCLUDE WRTRUNDT
-*
 USE
   &TMPDIR&FCFILE NEW AS FCAFCARS
 END
-RUN
-GOTO START.JOB
-*
-******************************************************************************
-******************************************************************************
-*
-SETUP.TEST
-*
-*  Test/Devel Environment
-*
-SET &&KIDS_SERVER=KIDSTEST;
-SET &TMPDIR='/opt/ibi/apps/jagtemp/';
-* -SET &TMPDIR=' ';
-* -SET &NEW=' ';
-SET &NEW=NEW;
-SET &CLIENTS='-*';
-* -SET &CLIENTS='(2586180,3043655,3043660,3043664,3079464,3079467,3190667,3319876,3320687)';
-SET &CLIENT_TST1=
- IF &CLIENTS EQ '-*' THEN '-*' ELSE 'AND T1.CL_ID IN &CLIENTS.EVAL';
-SET &CLIENT_TST2=
- IF &CLIENTS EQ '-*' THEN '-*' ELSE 'WHERE CLID IN &CLIENTS.EVAL';
-SET &CLIENT_TST3=
- IF &CLIENTS EQ '-*' THEN '-*' ELSE 'AND CL_ID IN &CLIENTS.EVAL';
-SET &CLIENT_TST4=
- IF &CLIENTS EQ '-*' THEN '-*' ELSE 'AND PT_CHLD_CLID IN &CLIENTS.EVAL';
-SET &CLIENT_TST5=
- IF &CLIENTS EQ '-*' THEN '-*' ELSE 'AND CL_ID IN &CLIENTS.EVAL';
-*
-* APP PATH baseapp masters testacx
 APP PATH jagtemp baseapp masters testacx
 APP HOLD jagtemp
-*
 USE
   &TMPDIR&FCFILE &NEW AS FCAFCARS
-*   &&BASEAPP&FCFILE AS FCAFCARS
 END
-RUN
-*
-IF &NEW EQ NEW THEN GOTO START.JOB;
-? &
-GOTO JGTEST
-*
-******************************************************************************
-******************************************************************************
-*
-START.JOB

This is at the beginning of the job, so when I need to make changes, I will copy the program to my working folder and set &PROD to TEST. That way, while testing, I can put files anywhere I want them while. When I done, I change &PROD back to PROD before moving the program back to its production folder.

Production jobs use the production APP PATH found in edasprof.

This works because my temp work folders, i.e. jagtemp are not in the Production APP PATH. This works well for us and jobs submitted from RC never have a problem finding temp files.

Another "standard" we use is that we store all of our .foc, .xfocus, any permanent .ftm files and their associated masters in BASEAPP.

Our Oracle masters are stored in a folder named masters. However, we store the .acx files in other folders, i.e. prodacx, testacx, trainacx, etc. Only prodacx is in the production APP PATH, so I never have to worry about a production job running against the clone (testacx) or training (trainacx) database.

I think if you rethink how your environment is setup, you'll be able to find a setup that will work.

This is actually an excellent way to deal with multiple databases/schemas. Actually we have parametrized our code to pass the database name, schema name along with other parameters. So we are using the same code for different environments. However, our problem is that we do not handle the environment set up. It is the WF Admin who will be able to grant us independant folders in other server instances so that the MFDs can be separated out.
We have the following folders in the same server instance:
dev, test, stage - all of these have the same set of MFDs, with only the acx files being different.

Still limping with the same issue!

Syed,

I'm a little confused about your comment regarding intermediate hold files. If you create a temporary hold file, it won't matter where it goes, it will still be found. If you've used APP HOLD or APP PREPENDPATH, it knows where that is. If it goes into EDATEMP, it knows where that is also. In you're example, it will refer back to ABC folder, but it won't find it there, so it will look in EDATEMP. WF will always look in edatemp if it doesn't filnd the TABLE elsewhere, so APPENDPATH or PREPENDPATH is not going to change that.

Now if you've created a HOLD file with the same name as another DBMS table and it's finding the wrong one, then that's the programmer's fault for using a bad hold file name.

I agree with jgelona in that you seem to be making this WAY more complicated than it needs to be.

Darin/Jgelona
Apologies for having confused you guys. However, when I discussed this issue with the WebFOCUS Admin team, they were convinced.
Actually we do not want to use APP PATH since our job creates several intermediate hold files. The same job needs to be executed in parallel with different parameters - this is the requirement.
When I schedule the job using RC, it does not recognize where to look for the MFDs and picks the MFDs randomly from different folders (since we have the MFDs with same name in a few other folders as well).
As I understand, the report caster should be able to understand that it needs to look for the MFDs in the default location where the fex file is placed.
Please let me know if this is an expected behaviour of report caster. If yes, then we do need to go the APP PATH way and figure out how to go about it.

Regards
Syed

Using WF 7.1.7/Dev Studio

Then I suggest you pick different names for your hold files that don't match master names in 'production' directories. Let the hold files with the 'new' names be written to EDATEMP (which is the default) and then each parallel execution of you focexec will have its own set of files and masters.

This is exactly what we are trying to do. we have got new names for all the hold files and they are not matching with the MFD names in other directories. However, the report execution through caster always picks up the MFDs from a different folder.
Is there some setting at the RC end which is kind of overriding its default behaviour of picking up the MFDs from the same location where the fex file is present?

Do an APP SHOWPATH in your focexec and run it from RC and see what it thinks the path is.

Your new names should NOT match anything in the path or this will not work.

The two sentences in the first paragraph of your last post contradict each other. The names can't be 'new' and match anything that already exists in another directory.

Hi,
I am from the same team as Syed and this is just a different projection of the issue we are facing:

We need to create 3 focus files each for 2 months like:
Focus file 1: Jan and Feb
Focus file 2: Mar and Apr
Focus file 3: May and Jun

For this we need to run same fex file except for a parameter value being different for each of these. So, what we have done is created 3 jobs in Report caster executing the same fex file but setting different value for a parameter being passed and based on the parameter focus files will get created for the required months.
Its all fine when we schedule the jobs one after the other, the focus files are getting created with the data for the expected months but when we try scheduling the jobs all at once(as is required), we are facing the following issues:
1. Sometimes, though the focus files get created without any error,it has unexpected data in the focus files like: Focus file 1 has data for jan, feb, may, jun and focus file 2 has data for mar, apr, jan feb and so on.
2. Some times we are ending up with the fixform error (THE FORMAT USED WITH FIXFORM IS INCOMPATIBLE WITH THE DATA FORMAT ). When we reschedule the job again then it comes fine without giving the fixform error.

We assumed that different jobs scheduled through report caster run in independent sessions, but looking at the output and the overlapping data , we doubt if its not 3 different independent sessions. To handle this, we made the names of the intermediate hold files dynamic as well to be unique but it doesnt help.
Fixform error can be avoided by removing APP PATH, but when the job is scheduled through a report caster, tables are not identified correctly unless we specify the APP PATH.

Look up TEMPDIR and the USE command and see if those might offer a workaround your issue.

You can use TEMPDIR to find out which edatemp directory you are using and USE to specifically point to the data base you are creating.

Report Caster and WebFOCUS do run programs in independent sessions or agents and each have their own tempdir or edatemp directory. I do not know why you are having such strange behaviour.

So each of the three files has its own filename, right?
If you have three jobs scheduled simultaneously, each connects to the WF server on its own agent, using its own EDATEMP space. If you HOLD a file (without any APP or FI commands) it goes to EDATEMP for that agent, and when the agent finished and disconnects, those hold files are not longer available for use.

So if you're wanting to create files that will be available after the job has finished you MUST use either a FILEDEF command to tell it to put the data elsewhere, or one of the APP redirect commands ( APP HOLD, APP HOLDDATA, APP HOLDMETA, APP FI). If the jobs are scheduled consecutively, they may or may not re-use an agent, but the HOLD files are still temporary.

Changing the app path (APP PREPENDPATH, APP APPENDPATH) doesn't really come into play anywhere in this scenario.

A couple other points, just for clarification. Either in the server profile (or manually by code) and application path is set with application folders in a specific search order. MFDs and procedures are not "randomly picked" from the path. They are always found according to the search path, so in your case where you have duplicate MFD names, it will search the app folders in the specified order and use the FIRST one it finds. EDATEMP is automatically appended to the APP PATH (as is baseapp).

Also, your assumption that "report caster should be able to understand that it needs to look for the MFDs in the default location where the fex file is placed" is not correct. WF always looks for MFDs in the app path order, regardless of where the fex is placed.

The APP commands (Search for "Application Commands Overview" in your documentation) can modify this behavior.

Last note - there is a setting SET TEMPERASE=OFF that leaves temporary files in EDATEMP after a disconnect, but as I see it, this would cause you even more confusion, and fill up available temporary space.

Hope this clears things up a little. If you are experiencing behavior other than this, something is not quite configured correctly or you have unknown commands somewhere (like edasprof) that are altering default behavior.

fact: 3 separate jobs in caster *will* run in 3 separate agents.
fact: Caster will use the path defined in your edasprof, unless that path is messed with in some way.
as ginny suggests, 1) look at your edasprof to see what your path is by default;
2) run a command from whatever domain you're in to query your path, make sure you get what you expect; 3) run a caster job with only path query statment.
What do you see?
Do you see what you expect? the same path as in your edasprof?
You need to do 2 things;
1) make sure caster can read the masters you *want* it to read. Let your fex point those masters to the proper data using a FILEDEF (if that's appropriate) or a USE statement (if thats appropriate)
2) make sure your jobs DO NOT park any of their interim data files ANYWHERE EXCEPT within the agent (edatemp directory) that is running each fex. commands such as TEMPDIR and those APP HOLD commands that hold interim files (APP HOLD, APP HOLDDATA, APP HOLDMETA) can be highly destructive unless used *very* carefully and knowingly. So many sites get cluttered with e-junk, files called HOLD left over from sloppy programmers.

i just read darin's post...really good explanation.

Funny that we both posted such verbose explanations that both essentially say the same thing. Great minds, huh?

Susannah,

I messed up. I didn't meant TEMPDIR; I meant TEMPPATH, a cool way to get the name of the edatemp directory you are working in:

-SET &TPATH = TEMPPATH(80, 'A80');
-TYPE &TPATH

Here is example output from these 2 statements:

D:\ibi\srv521\wfs\edatemp\ts000070\

You can then use the variable in filedefs. Very cool if you are using alternate master techniques.

Hi again
After reading so many great posts and having acquired some knowledge on the various aspects of scheduling, we have decided to keep only one version of MFDs in our environment. Let there be no conflicts!
Now - we are using APP HOLD and tried to use APP DELETEF FOC$HOLD MASTER
APP DELETEF FOC$HOLD FOCTEMP at the end.
When i schedule the jobs one by one, all of them are created perfectly! However, parallel scheduling results in the creation of all FOCUS files with same data! My understanding is that this happens because the temp file (FOC$HOLD) gets deleted by one of the fex files (APP DELETEF).
Doesn't WF create different FOC$HOLD files for different threads? Is there any way we can avoid this?
Sorry for bothering all of you with my recurring issue - but since this forum has always resolved my issue, I'm positive that I will get a solution here!

Thanks for all your great posts guys and for your responses so far.

Regards
Syed

Using WF 7.1.7/Dev Studio

Forgot to mention - we did try to use
-SET &WORKDIR = TEMPPATH(80,’A80’);
APP MAP WORKDIR &WORKDIR

APP COPYF WORKDIR &P_LPFDB FOCUS &P_LPFDB FOCUS

APP COPYF WORKDIR &P_LPFDB MASTER &P_LPFDB MASTER

but this gave the following error:
(FOC32429) USER HAS NO RIGHTS TO EXECUTE MAP WORKDIR

Regards
Syed

Using WF 7.1.7/Dev Studio

your fex is trying to make a focus file,is that it?
Drop all the APP commands out of your fex.
USE
D:\IBI\APPS\....wherever..\MYFOCUSFILE.FOC NEW
END
TABLE FILE....
build your focus file
END
-RUN
CMD COPY MYFOCUSFILE.MAS D:\IBI\APPS\...wherever youkeep your masters...\MYFOCUSFILE.MAS /Y
...
Leave all the APP commands out of your fex and all your interim work files should then get made in your agent directory, which evaporates when the fex is done. Force only the final .FOC and its .MAS to be retained. The USE statement tells focus where to park the final file. The COPY statement explicitly puts the master whereever youwant it.
Once you understand how this works at its most basic level. *then* you can start experimenting with APP commands.

Hi Susannah
I am able to create the FOCUS file using USE command as you had suggested. Do I need to copy the masters also in the application folder which I want the FOCUS files to be in? Can't I reuse the existing masters, if I know that there will not be any change in the MFDs.
FYI when I rey to query the FOCUS files after they have been created using the USE command, I get 'NO DATA FOUND FOR THE FOCUS FILE NAMED: LPF_ST' error, although I am able to see this FOCUS file in my app folder with a size of around 40 MB.
Is there anything else which I need to do to make it work?

Regards
Syed

I have found by experimentation (a FEX containing only APP SHOWPATH) that when you activate the 'Application Path' property of either an MRE Domain or an MRE Standard Report, the Apps directory/ies listed in the box are 'APP PREPENDED' to the application path in place when the standard report is executed. If both the Domain and the StdRpt have their 'Application Path' turned on and specified, then the Domain's is PREPENDED to the existing path first, and the StdRpt's is also PREPENDED to that just expanded path. This causes the search to proceed first through the StdRpt's path, then the Domain's path, the UserID's own profile (if it contains any pathing specification), and finally the EDASPROF path. This pattern can be further altered, if the FEX contains additional, internal, APP PREPENDPATH statements, each applied in the order in which they are encountered. If the FEX contains a simple APP PATH, then tha blows away and replaces all foregoing APP PREPENDPATH activity.

So Syed, examine the properties of your Domains and Standard Rreports to see it their 'Application Path' properties are activated.

Did you notice I said, above, "directory/ies "? Yes, the Domain or StdRpt 'Application Path' box can contain a list of Apps directories, and they are searched in the sequence they are mentioned. Also, I've found that if you misspelling the name of a pathed directory, FOCUS does not issue a "I can't find this app directory" message. The searching continues on to the next directory in sequence, acting as if the target was not found in the 'phantom' directory. (I found this 'feature' useful to label path specifications so that when I examined the whole path disclosed by APP SHOWPATH, I could see where each path segment originated, eg "APP PREPENDPATH DOMPATH CARS TRUCKS BIKES" )

Lastly, all of the above does not apply when executing via the "Self Service" mode, in which the FEX lies in an App directory, outside of the Domain or Standard Report hierarchy.

Chris Burtt

Great post Susannah! That worked perfectly in my case.