Background. Our application of WebFOCUS allows users to execute reports online. We also execute the same reports in FOCUS overnight via a scheduled batch process. (Note: We do not use ReportCaster.) The overnight reports are placed in an external repository for archival purposes.

Problem. Need to identify when a procedure is executed via WebFOCUS or when it is executed via FOCUS. The reason for requirement is that not all WebFOCUS code executes in FOCUS.

Question. Is there a variable (or something) that may be examined which will identify the environment (WebFOCUS versus FOCUS) where the procedure is executing? I want to keep the solution simple if possible.

Thoughts and suggestions appreciated.
Grazie.

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

You may be able to use system variables &FOCMODE and/or &FOCREL to differentiate between the two environments.

Is it possible to 'detect' the difference by checking &IBI_user, &IBIMR_domain, &IBIMR_user or &REM_UID ?

Assuming the 'overnight batch process' is executed under a different username than the "WebFOCUS users" at daytime?

If not... ...you might consider making a special useraccount for the night processing.


Just a thought...

Thank you for your input.

Results. &FOCMODE and &FOCREL result with the same values in WebFOCUS and FOCUS. &IBI_user, &IBIMR_domain, &IBIMR_user are WebFOCUS variables and will not work in FOCUS. &REM_UID is not a system variable. WebFOCUS and FOCUS prompt for its value at execution time.

Any other ideas would be appreciated.
Grazie.

The command below will display a list of variables, system and otherwise. If you run it in both environments, perhaps you can find something different between the two.

-? &

Are you truly running FOCUS or are you running a standalone tscom, i.e. edastart script, for your batch processing? A thought is that the batch process could start with a standard or preprocessing procedure that overrides or resets a global variable that is also set in the WebFOCUS global profile. That would give you the most control, I think.

I second Dan's suggestion. We had a similar situation when the same program was to be executed Ad-hoc and also from ReportCaster, but with slight variations.

Doing the (-? &) on both sides showed me that environment variable &FOCFOCEXEC has a special value of 'RCASTER' when run from RC. We trapped this value right at the top of the program to determine further execution modes.

Did you also consider checking the executing User-ID? All your batch executions may be under one system-ID and when run ad-hoc, there would be different user-ids. You could use this trap if it works in your situation.

Hope that helps.
Sandeep Mamidenna

Again, thank you for your input.

Results.
Dan. -? & produces subtle differences between the two environments. For example, &FOCFEXNAME in WebFOCUS does not have an extension whereas in FOCUS it does.
WebFOCUS &FOCFEXNAME = paydates
FOCUS &FOCFEXNAME = paydates.fex
Although it is possible to use the difference for the purpose I require, I would not feel confident that this doesn't change in a future release of WebFOCUS/FOCUS.

Ginny. FOCUS is running as a stand-alone tscom via an edastart script. As suggested, it is possible to add a preprocess to the FOCUS script to set a variable that could be used to identify FOCUS execution. I have considered this approach and to some extent have already included this functionality in some of the procedures.

Blue. I did -? & on both sides - WebFOCUS and FOCUS. The common variable have the same values (exception noted above). Variables that are not common to both sides fail resulting in an error. The error is not usable. I have checked the User ID. Although it should be different, WebFOCUS/FOCUS displays the same ID. I will give this more consideration.

Again, I thank you for your input. I was hoping for a variable that would make this simple and therefore easy to maintain by other developers.

On the Mainframe, modify profile.prf and add:
-SET &&ENV = 'TSO'; or
-SET &&ENV = 'MSO'; whichever it is

On Windows, modify edasprof.prf and add:
-SET &&ENV = 'WINDOWS';

Now, when you do -? &, the &&ENV should show the appropriate environment...

hth

If the non-existance of a specific field is guaranteed on one of the sides, then you could also use the .EXISTS check for determining your execution mode.

However Tom's suggestion sure looks fool-proof.

Results.
Tom. Mainframe FOCUS is not involved. FOCUS is running as a stand-alone tscom via and edastart script.

Solution.
Blue. Your suggestion using USERID was excellent. The GETUSER function works for the purpose required. The value for WebFOCUS versus FOCUS is different. Will add Dialogue Manager statement to the procedure
-SET &XUSER = GETUSER(USERID);
and use the variable value to identify the environment (WebFOCUS versus FOCUS) where the procedure is executing.

My sincere thanks to everyone.
Molto grazie.

quote:

However Tom's suggestion sure looks fool-proof.

I second that! What Tom suggests not only gives you more control over the variables and values you can set to identify each of your environments but also shelters you from potential issues derived from future [Web]FOCUS releases; if you set your logic based on a variable that is guaranteed not to exist today in one of your environments but later down the road IBI decides that such a variable should become available for all platforms in a new release ... well, you know what will happen.

FOCUS - always calls profile.prf during execution
WebFOCUS - always calls edasprof.prf during execution

You have found a solution, that is a good thing!