&IBIMR_domain identifies the name of the domain in mre.
but for backend apps where there are fexes (argh!), is there some similar way to get an &IBI variable that would grab me the app name, ie the location of that fex?
TIA
-s

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

There's this:

Posted Aug 09, 2007 12:19

I'd love to find something better!

ahhhhhhh
yes
syscolumn
ok that's the only way...
i can't use it b/c i'll have 10 apps with the same fexname in them
(i work in multi-developer bedlam w/ no one following rules)
but muchas gracias, francesco

Susannah,

As for the physical location of the file you could (mis)use tracing.
It will not give you the app name however. But if the location is enough for you, then:

SET TRACEOFF = ALL
SET TRACEON = ALL
SET TRACESTAMP=OFF
SET TRACEUSER=C:\TEMP\TEST.TRC
-RUN
WHENCE &FOCFEXNAME FOCEXEC
SET TRACEOFF = ALL
-RUN
FILEDEF MASTER DISK TRACE.MAS
FILEDEF TRACE DISK C:\TEMP\TEST.TRC
-RUN
-WRITE MASTER FILENAME=TRACE, SUFFIX=FIX
-WRITE MASTER SEGNAME=TRACE
-WRITE MASTER FIELDNAME=LINE, FORMAT=A200, ACTUAL=A200, $
-RUN
DEFINE FILE TRACE
RESULT/A150 = SUBSTR(200,LINE,50,200,150,RESULT);
END
TABLE FILE TRACE
PRINT RESULT
IF LINE CONTAINS 'ngput'
END
  

Hope this helps ...

This was the other method discussed in the thread I posted:

-SET &ECHO=ALL;

-DEFAULT &PROGRAM1 = 'NCRR004';

-SET &PROGRAM1 = LOCASE(&PROGRAM1.LENGTH, &PROGRAM1, 'A&PROGRAM1.LENGTH');

SQL FMI SET SYSFILES FOCEXEC
-RUN

DEFINE FILE SYSFILES
FILENAME1/A64 = LOCASE(64, FILENAME, 'A64');
END
-RUN

TABLE FILE SYSFILES
PRINT
PHNAME
WHERE FILENAME1 EQ '&PROGRAM1';
ON TABLE HOLD AS H001 FORMAT ALPHA
END
-RUN

-READ H001 &PHNAME.A80.

-TYPE PROGRAM LOCATION: &PHNAME

Expanding on FM's code, here's a fex (analogous to the WHENCE command), to return the folder and full path of a file's location in global &vars.

  
-* whence.fex * Jack Gross * 3/2009
-* takes:  &1 [or &FILE], &2 [or &TYPE default=FOCEXEC]
-* sets:
-*  &&fPATH   = portion of full file-id up to last separator (inclusive);
-*  &&fFOLDER = portion of &&fPATH between last two separators;
-* both trimmed, both blank if file not found.
-* See: \ibi\srv76\home\catalog\sysfiles.mas
-DEFAULT &FILE = ?       , &1=' ';
-DEFAULT &TYPE = FOCEXEC , &2=' ';
-SET &FILE = IF &1 NE ' ' THEN &1 ELSE &FILE ;
-SET &TYPE = IF &2 NE ' ' THEN &2 ELSE &TYPE ;
-SET &TYPE=UPCASE(&TYPE.LENGTH,&TYPE,'A&TYPE.LENGTH');
SQL FMI SET SYSFILES &TYPE
DEFINE FILE SYSFILES
  SEP/A1=IF PHNAME CONTAINS '\' THEN '\' ELSE '/';
  REVERSE/A80=REVERSE(80, PHNAME, 'A80');
  RFOLDER/A80=GETTOK(REVERSE, 80, 2, SEP, 80, 'A80');
  RPATH/A80=SUBSTR(80, REVERSE, POSIT(REVERSE, 80, SEP, 1, 'I2'), 80, 80, 'A80');
  FOLDER/A80=LJUST(80, REVERSE(80, RFOLDER, 'A80'), 'A80');
  PATH/A80=LJUST(80, REVERSE(80, RPATH, 'A80'), 'A80');
  FILENAME1/A64 = LOCASE(64, FILENAME, 'A64');
END
-SET &file = LOCASE(&FILE.LENGTH, &FILE, 'A&FILE.LENGTH');
TABLE FILE SYSFILES
  PRINT PATH FOLDER
  WHERE FILENAME1 EQ '&file';
  ON TABLE HOLD AS H001 FORMAT ALPHA
END
-RUN
-SET &read = IF &LINES EQ 0 THEN '*' ELSE 'READ';
-SET &foldr = ' ';
-SET &fpath = ' ';
-&read.EVAL H001 &fpath.A80. &foldr.A80.
-SET &len=MAX(1, ARGLEN(&foldr.LENGTH, &foldr, 'I3'));
-SET &&fFOLDER=SUBSTR(&foldr.LENGTH, &foldr, 1, &len, &len, 'A&len.EVAL');
-SET &len=MAX(1, ARGLEN(&fpath.LENGTH, &fpath, 'I3'));
-SET &&fPATH=SUBSTR(&fpath.LENGTH, &fpath, 1, &len, &len, 'A&len.EVAL');
-TYPE *
-TYPE * WHENCE '&FILE, &TYPE' * &|FOLDER: (&&fFOLDER) * &|PATH: (&&fPATH) *
-TYPE *

all very very clever
from the best of the best minds.

and all still dependent on there being only one instance of a given fexname in the app universe.
and in bedlam-land, where i live, ain't gonna happen.

I tried quite hard to use the DB_LOOKUP function on table SYSFILES but that didn't work...

But even with very many apps with all the same fexnames, you have to have a means to instruct the server which of those fexes to run. And only after that has been established, then you could use one of the methods above. The server cannot execute more than one fex simultaneously in the same session, so the &FOCFEXNAME is populated with the correct name, and the WHENCE will give you the path the server used to reach the fex.

Or is there still some other underlying problem that you have that I do not see at the moment?

oh i see what you're saying GAmp
the WHENCE is operating after the
APP PATH whatever
has locked the path down,
so your trace method of grabbing the output of a WHENCE command would in fact give me the app,
with alot of work.
ok
got it
bless your heart.

From Tech Support (I opened a case):

quote:

... Programming are looking at ways to accomplish this with lots of different commands. However this is just in the talking stage and it still has not been decided if or when it will be done. Some of the other commands would be; ? FILE, ? FDT, ?FF, etc.
As of now we don't have any way of doing this....

wow. they totally missed the point.

One thing you can consider is using APP PREPENDPATH in your session to force the APPPATH to be what you want it to be. This will ensure that you pick up the Focexec from the correct application. However, this also has a big drawback. Now you are 'aiding and abetting' the programmer bedlam, and there is no motivation to follow the rules.

D, i'm trying to extract an &var so i can put it in my usage log, like &IBIMR_domain

quote:

this is still being discussed and still without agreement as to impliment or not. You may well help by bring this up though either FOCAL point for Ibug. and Yes many clients have requested this

- Tech Support

quote:

Francis, I have spoken with the division, and they suggest the folowing:
1) Please provide a precise example of what you are trying to accomplish.
2) A Business reason for the feature.
This will assist them in discussibf this with programming.

- Tech Support

that's so sad.
it would be hilarious
if it weren't so so so sad

How about trying this. The USERPATH subroutine returns the APPPATH part of ? PATH

On Windows you have to manipulate the variable because a bug means it misses inserting the ;
after the first one.

 
-SET &INFEX=testg;
-SET &CNTR=0;
-SET &APPPATH=USERPATH(256,'A256');
-SET &APPPATH=TRUNCATE(&APPPATH);
-*
-* needed because of a bug
-SET &APPPATH=STRREP(&APPPATH.LENGTH, '&APPPATH.EVAL', 2, 'C:', 3,';C:', 256, 'A256');
-SET &APPPATH=STRREP(256, '&APPPATH.EVAL', 2, ';;', 1,';', 256, 'A256');
-SET &APPPATH=TRUNCATE(&APPPATH);
-*
-REPEAT ENDWHEREIS 99 TIMES
-SET &CNTR=&CNTR+1;
-SET &APP=GETTOK('&APPPATH.EVAL', &APPPATH.LENGTH, &CNTR.EVAL, ';', 256, 'A256');
-SET &FOCEXEC= TRUNCATE(&APP) || '\&INFEX.EVAL.fex';
! STATE &FOCEXEC
-IF &RETCODE EQ 0 GOTO GOTAPP;
-IF &APP EQ '' GOTO GOTAPP;
-ENDWHEREIS
-GOTAPP
-TYPE the Focexec is &FOCEXEC
 

JG, I get a blank for USERPATH on both Windows and UNIX.

I changed

-SET &APPPATH=USERPATH(256,'A256');

to

-SET &APPPATH=FGETENV(256, 'USERPATH', 256, 'A256');

but that did not work either.

Francis,

I've tested it in 762 and 768 and it works fine.
the ; bug is in both releases.

From what I've been able to read FGETENV and FPUTENV do not work as it's a memory resident setting.

I have found no documentation on using USERPATH as a function. USERPATH is only mentioned as an environment variable not to be used in the FPUTENV, "Limit: You cannot use FPUTENV to set or change FOCPRINT, FOCPATH, or USERPATH; once
started, these variables are held in memory and not reread from the environment."

I wonder why USERPATH as a function or a variable name in the FGETENV function returns blank.

OK, in my environment,

-SET &APPPATH=USERPATH(400,'A400');

works, the path is longer than 256 characters.

On my environment, unix, nosuch animal
i just crashed my server (wheeeee!)
with
-SET &APPPATH=USERPATH(900,'A900');

I have seen some hottracks in different versions where a path greater than 256 has caused problems.

An attempt but not a solution because of bugs.

Funny, I tried it on my local Windows server with 2048 and that worked.

OK. I've just done a bit more testing and it's a good one.

both windows and unix have the same bugs.

On windows it does not insert the ; delimiter after the first one.
On Unix it does not insert the : delimiter after the first one.

On both systems you can specify a length of the returned variable of up to 32K and everything works
with the function actually returning a variable 32K long.

PROVIDING the physical length of the path is less than about 530 bytes

If the physical path is greater than about 530 then it crashes the session.

crash-on-demand might be an interesting feature