Question How to find the .p's and .i's inside a program

[Narasimhan]

Hi Friends,

How to find the list of .p's and .i's inside a program after importing it ?

define var ch1 as character format "x(60)" no-undo.
input from "/home/mfg/odn2d/src/xxapmta5.p" .
repeat:
import unformatted ch1.
if ch1 matches "*~~.p" then display ch1 .
end.

I used the above query but it does not work. I need to find list of calling .p's and .i's which were used on the program imported . Thanks for your help in advance.

Regards,
Narasimhan. D

 

[acejimmyster]

Hi,
If you just try to get the program list of calling .p or .i file, you can download a 3party tool to grep the code folder with your .p or .i name. There are a lot on Internet.

 

[Cringer]

1) There's no need to post your query everywhere - additional posts deleted.
2) Did you bother to look at the recent threads? How about this one? http://www.progresstalk.com/threads/searching-i-and-p-files-inside-a-procedure.121870/

 

[Narasimhan]

I have an issue here, I have a big list of programs on which I have list of standard .p's and on other hand custom onces. Hence I have trying to write a program which import a program read all .i's and .p's line by line. With those .p's I am checking with a custom folder where custom programs are placed using search() key word and to skip the .i's and .p's which were not available on the custom path. But I guess search() is case sensitive, if the file on the program were wrote on upper lower case combilnation its not finding them. For example, on a program it was written as gprup{xxmorsl.p} and on program the program as named as xxMorsl.p then its not finding this program. Also, I tried couple of third party tool but nothing gives the report on excel. If you know one please advise.

Also, i reviewed the link you provided and I guess on my initial query I did used "*~~.p" but still it not working since I am importing the program.

 

[Cringer]

Are you running on Unix or Windows?

 

[Narasimhan]

I am running on Unix

 

[Cringer]

Then yes it will be case sensitive. I really think you'll be better placed to use a tool that's not progress to find the references. I'm no Unix expert but can't you use Grep to find out what you need?

 

[Narasimhan]

In fact grep was my first option to try this. But grep works in a different way, if I use grep for main .p it will bring list of .p on which this main .p has been used. Wise versa if I use grep for calling .p it will again bring a list of .p's on which this .p has been called for. Hence either ways I am not able to find the list of .p's and .i's which has been used under particular program. I even tried grep by righting a script for that. But still grep logic just bring just the list of file on which this particular word is been used. Can you refer any software/link which helps me to bring this list on an excel form?

I really appreciate your help and time which you are spending for me on this issue.

Regards,
Narasimhan. D

 

[TomBascom]

What do you mean by "but it does not work"?

Are you saying that:

if ch1 matches "*~~.p" then display ch1 .

Misses patterns that you expect it to find?

You are importing an entire line into ch1 -- so I would expect it to be rare that it finds a match as described since most of what you are looking for will be something like:

run program.p.

or

run program.p.  /* some comment */

or

run program.p ( input someparameter ).

and the characters after the ".p" are not being wild-carded.

Parsing code is a hard problem. You would be well advised to use a tool designed for the purpose.

 

[tamhas]

Grep and similar text oriented tools are not ABL-syntax aware and thus likely to make a number of predictable mistakes, e.g., run and the program name on the next line. Trying to use ABL to search and pattern match is likely to be even more unsatisfactory since it is both slow and weak at the task. To do this in a predictable way, one needs to use an ABL-syntax aware tool. The most well known is Proparse. One can do a thing called Proparse scripting to have Proparse parse a particular compile unit and then loop through the AST to find RUN statements. This is a little trickly to get started, but not ultimately that complicated to do. Two caveats. Proparse is no longer being updated and does not recognize any 11.x syntax. And, Proparse on its own cannot resolve dynamic calls, e.g., RUN VALUE() and superprocedure references and the like. Analyst does a good job of resolving all of the possible Callgraph and has a nice browser, but is no longer being sold, although I might be able to get a copy, but with support only on a pay as you go process. Gilles Querret of Riverside software is coming out with a new tool that might cover this requirement and it uses the parser from PDS/OEA, so will be fully current, but that is probably end of the year.

 

[GregTomkins]

Can't you just do COMPILE XREF and parse the RUN (and/or INCLUDE) references from the XREF listing? This would be 100% reliable, I think. I guess the downside is that the file has to be compilable and you have to have an appropriate compiler.

 

[TomBascom]

That won't find the dynamic RUN targets.

But it would certainly be much more reliable than "grep"ing source or writing your own parser in the ABL.

 

[GregTomkins]

Good point, and for sake of completeness, note there are at least four versions of 'dynamic run targets':

1. RUN VALUE
2. The CALL object
3. DYNAMIC-FUNCTION
4. Code that actually writes .p's and executes them on the fly

None of these would be reliably resolvable using any form of parsing. That doesn't mean it's not worth doing, though --- we do this (the COMPILE XREF thing) and it's OK for us based on we almost never do #1 and while we do #2 and #4 a lot, we only do it in very specific situations that we account for.

 

[tamhas]

Note there are other dynamic calls. RUN x IN y where y is a handle that is set within the compile unit is analyzable, but would not come out of any of the simpler techniques. If the handle is passed in, then one actually has to analyze possible callgraphs to determine what compile unit y might stand for. Superprocedures are worse because there isn't even a handle to track down. Analyst manages this by doing what it can with the callgraph, including traceback to find possible superprocedure names, and then also has a provision for "hints". I.e., one can run a report about all the unresolved calls, then provide some information to Analyst so that it can resolve these links in subsequent passes. I think this is important since only frequent fresh passes will guarantee that the references are still accurate. Depending on the application, many dynamic calls can be easily resolved. E.g., many systems have their menu system in a DB table. That table provides all the information needed to resolve all the menu related RUN VALUE() statements.

 

[Narasimhan]

Thank you all for your inputs and they are great. Just one more question here, how about using strings option on .r and is there is any way that we can get only their used .p's and .i's. Since when ever I use strings it show me a big list which ends up with their called ones. Can we have it cut down and get only their called .p and .i's.

 

[vignesh]

Hi All,

Anyone have any suggestions please,.

 

[Narasimhan]

Hi All,

I searched on google but I don't fine one. Can any one provide me with the link which helps me to download the software which provides me the details of calling .p's . Thank you so much for your helps