Detecing Program Calls

cluc

New Member
Hi All,

Just a quick intro on my knowledge: I have been developing software using Progress for almost about a year now, still learning though. Although I had no training with the Language, but had similar ones like VB, SQL and other languages such as C, C++, Java, etc, I find that it's not so hard once you get the idea and syntax.

Anyways, I was wondering if there are any code (Syntax)/Handel, which can detect what sort of programs are being ran.
So instead of adding a call procedure in every program, I just have the one that can run in the background and detect what programs get called and ran.

Is there such method?

I mean, it would make life easier, instead of inserting a procedure call in every single program to register itself that it has been called or ran.

The reason why I'm trying to implement this is because, it could make things simpler for developers to detect where or which programs are involve in a specific call or if an issue occured, where we can look. Instead of going through each programs checking the logic and tracing it slowly.

Anyways, hope all can help or advise.

Cheers,
 
For debugging (I presume that's what you're after), there is the -debugalert parameter/session attribute. This adds a Help button to message boxes which displays procedure stack. You can also implement it in an Appserver environment to show call details.

There is also ProTools/Prospy, and of course your actual Debugger.

These are development, rather than deployment tools though.

HTH

Lee
 
If you want to see what programs are in the stack without having to insert a message in the code, you can write a little program that does the same thing and lists the stack by means of the PROGRAM-NAME(x) function (see online help for details). Doing that allows you to create a little user interface trigger that can run the program at any time.

Also, you can traverse the tree of currently running persistent procedures within the session by traversing the tree of persistent procedure handles. You can find these by getting the SESSION:FIRST-PROCEDURE handle and then traversing the tree with NEXT-SIBLING. Of course, listing the persistent procedures like that shows ALL persistent procedures of the session and that means you may see some that have nothing to do with the procedure you are currently in.
 
Check out the following commandline parameters, they are well documented in OE10 but in 9.1D they seem to fall in the realm of vaguely identified:

-clientlog c:\temp\client.log -debugalert -logginglevel 7 -logentrytypes 7

These parameters will turn on 4GLTrace level logging into the clientlog file and will record every procedure/function call along with the parameters passed to those procedures.

I orginially came across these from a appserver broker parameters and tried them on a regular client session and it is great for seeing where the application is going.

William.
 
PUBLISH & SUBSCRIBE mecanism here.

If you want to see what programs are in the stack without having to insert a message in the code, you can write a little program that does the same thing and lists the stack by means of the PROGRAM-NAME(x) function (see online help for details). Doing that allows you to create a little user interface trigger that can run the program at any time.

RE: If you do not want messages then output to a txt file.

Regards
 
wrpkm said:
Check out the following commandline parameters, they are well documented in OE10 but in 9.1D they seem to fall in the realm of vaguely identified:

-clientlog c:\temp\client.log -debugalert -logginglevel 7 -logentrytypes 7

These parameters will turn on 4GLTrace level logging into the clientlog file and will record every procedure/function call along with the parameters passed to those procedures.

I orginially came across these from a appserver broker parameters and tried them on a regular client session and it is great for seeing where the application is going.

William.


Very useful. Thanks.

Lee
 
for V9 it's -logginglevel 4 -logentrytypes 2

see: KB P13785

But beware the logfiles grow enormously.... :-)

Casper.
 
Thank You All.
I'm going to try it now.
I guess it sounds more like development... true true... sorry.

But I thought I could write up something for the developers to use... or for myself and make things easier.

But thanks for everyones time in explaining and giving me different approaches, appreciated, will try them all out.

Cheers

Calv.
 
Casper said:
for V9 it's -logginglevel 4 -logentrytypes 2

see: KB P13785

But beware the logfiles grow enormously.... :-)

Casper.

Actually there appears to be a number of undocumented values that go up to 9 for each value, the most effective values that I have used is 7 for level and types.

Compare using the values quoted to level 7 and you will see a difference.

William.
 
hi,

dont know whether you have seen the -yx parameter for proc.mon. This gives the programs that was run and the time each took to run (cost of the run).
 
There is also the 4GL Profiler, this can be turned on and it will record all procedure calls until it is turned off and then the output files can be loaded into the Profiler Session Viewer to see which programs were called and how long each call was taking.

William.
 
I was running the Pro*spy... it seems to crash if the program calls are a lot.
hehehe but it did help, shows me what programs are being called and what parameter values are passed through. but the output values are not shown...

Yep, I seen pro.mon.
I sort of wanting to create something similar to pro*spy... running in the back ground while running the application, but I guess it's really only needed when debugging... hmmm...

But thanks again everyone.

Cheers
Calv
 
Back
Top