Path-Vu or program 'cascade' utility 1

[MarcLodge]

Hi All,
I've used a tool called Path-Vu (or something similar) before, which produced a hierarchy of a program's sections and paragraphs. Does anybody know (and I'm expecting a big No on this one) if there is a tool that will read thru Cobol source, picking up all the programs that the source calls, and building them into the original program?!

The reason being is that I am working on a conversion from HPS to Cobol where the HPS code is made up of literally hundreds of small modules. When these are converted, we are left with hundreds of tiny Cobol program. What would normally be one 3000 line Cobol program turns out being 130 programs/subroutines. What I'd really like to do is supply a library, and a start program to a utility, and end up with a beautifully structured program which contained all the sub (and sub and sub) programs in sections/paragraphs.

Over to you. I'd be surprised if there is, but you never know.....

Marc

 

[k5tm]

Marc,

First of all have you seen the following technical paper?

http://www1.tepkom.ru/users/ddt/Articles/AutomatingLanguageConversion.pdf

And a question/suggestion re your post:

Perhaps this is a place to use nested subprograms and CALLs rather than paragraphs and PERFORMs?

If not, if the resulting programs are close enough in structure, you might be able to write a VB hack, using the VBScript Regular Expressions library to postprocess the conversion output into the style of program you are wanting. Tom Morrison

 

[MarcLodge]

Tom,
I had not seen the paper and am quite frankly and totally blown away by it! I won't go into too much boring detail, but I have just duplicated what the people who wrote the paper have done. I was oblivious that other people were performing similar tasks, and it's interesting to have an insight into their methods. If you have any other information, background or otherwise, on this paper, I'd be very grateful. How on earth did you come to hear about it?!

The main problem with converting any language to another is that if you put garbage in, you'll get garbage out. And this is my current problem. One HPS 'frontier rule' consisting of 130 smaller rules, converts to One Cobol program calling 130 smaller Cobol programs. Supporting this is a nightmare as everytime you want to do something (like access a DB2 table) you have to look at the source for at least one other program. What I'd like to be able to do is run a program that goes down each called subroutine and draws that code back into the calling program. Obviously this would coded in a nicely structured fashion!

I'm aware that what I'm looking for is more than likely a dream, but I thought I'd raise it with people here, just to see if anybody had come across any utility of this type.

Thanks for the link to the paper Tom, and I still can't get over it!

Regards,
Marc

 

[k5tm]

Marc,

Thanks for the star! I found the paper through a series of web searches on Google, since I had only the most vague notion of what HPS is.

I am sure there exist elegant tools that could build code trees and do the code promotion that you are seeking. I also think that such tools will be expensive.

That is why I recommend a VB hack, using the VBScript Regular Expression object. (See

http://msdn.microsoft.com/library/d...n-us/script56/html/reconCharacterMatching.asp

and

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/vsobjRegExp.asp)

I would scan the set of subprograms you want to promote to the mainline code, writing the working-storage and procedure lines to separate files identified by the program-id name. This would result in a 'database' of code that you would use in phase 2.

Phase 2 would be to scan the mainline routines you intend to keep, looking for CALL statements that call the routines you have in your 'database'. You can replace the CALL statement immediately as you go, and make a note of the working-storage elements that you need. Then you can pass the source once again, this time inserting the working-storage elements in the data division. Refinements might be necessary. For example, if the CALLed routines had formal parameters (linkage section) then you must parse the CALL statement enough to allow your process to build MOVE statements or otherwise deal with changing the formal parameter references in the CALLed routine to actual parameter references in the in-lined code.

Just some thoughts... Tom Morrison