DCL analysis / tools

[John Tannahill]

I have about 100K lines of DCL code to sort out. Are there any tools out there that will help me do this? In particular, something that will parse the "@" calls. Many of these calls are of the form @'name' which increases the complexity of creating a script to do it myself.

Thanks,
John

[Karl Rohwedder]

John,

what do you mean 'sort out'? Charlie Hammonds DCL_CHECK tool it helpful in finding coding errors/typos, but didn't go into @ed procedures.

regards Kalle

[Jon Pinkley]

John,

As Karl said, it depends what your goals are.

Any 'static' analysis isn't going to be able to find all the possible execution paths in an arbitrary DCL procedure.

The case you give of @'name' is much easier to find than something like

$ abc = " ''name'"
...
$ abc[0,8] = 64
...
$ 'abc'

If I found something similar to that in a command procedure, it would raise red flags, because it appears to be intentional obfuscation.

Without some assists from DCL itself, I don't know of any easy way to determine what files DCL is getting its commands from.

I am not aware of any magic logical names to turn on DCL procedure tracing.

There are "undocumented" tools like set watch file/class=all that will show all XQP related operations, but depending on what the command procedures are doing, you may get so much output that finding what you are looking for as hard as other approaches.

If you have never seen what this does and want to know, Google for â set watch fileâ

Perhaps you have just been given support responsibility for the code, and if thatâ s the case, I donâ t know of any magic bullets to help you understand what the code does. I would recommend that whenever you have to go into the procedures to find a problem, once you have determined the cause, that you add comments that you will find useful in the future.

Good luck,

Jon

[Dean McGorrill]

John,
I'll second the what do you mean sort out question. if you mean your stuck maintaining it, thats a lot of dcl. I have
worked on some big ones, strategic inquires in places or exits help, kind of like breakpoints. dcl is powerful, but easy to
get cute coding in it, making it tough to
maintain. Dean

[Hoff]

There are no direct tools available here that I'm aware of.

DCL is a limited environment, and there are a number of wrinkles around string handling and such that make processing it difficult. The apostrophe substitution is just the tip; found any ampersand substitution lurking in the code yet? :-)

DCL_CHECK and various other tools can be used to clean up the program, and there's likely a DCL lint around.

You can use indirect techniques to watch for the @ operations, such as the (undocumented) SET WATCH /CLASS=kw FILE command, and security auditing. These are fairly ugly and tedious approaches, though functional.

100,000 lines? That's a very substantial investment in DCL.

Stephen Hoffman
HoffmanLabs LLC
"Writing Real Programs in DCL, 2nd Ed"

[Ruud Dijt]

John
You can change all the â @â signs to â executeâ
You then get something like this $ â executeâ john.com

Depending if you go for a test or for real you can do the following

If it is a TEST $ IF â â â p1â â .eqs. â TESTâ then $ execute=â DIR â or a execute = â TYPE â and you check the existence of all the imbedded command files to execute

or

if it is for REAL $ IF â â â p1â â .eqs. â REALâ then $ execute = â @â and you get the real execution of the stuff.

For better reading sea attachment

[Ruud Dijt]

the attachment

[Anton van Ruitenbeek]

John,

Do you mean with sort out, look and know how procedures are called and stacked in eachother ?

AvR

[Jon Pinkley]

John,

In my reply of Aug 22, 2007 19:32:09 GMT, I stated:
------------
There are "undocumented" tools like set watch file/class=all that will show all XQP related operations, but depending on what the command procedures are doing, you may get so much output that finding what you are looking for as hard as other approaches.
------------

I tried doing this, and to my surprise, it does not display any file activity related to DCL opening command procedures via the "@"

Here's the command file I used on Alpha VMS 7.3-2

Contents of set_watch_file.com
-------------
$ ver='f$verify(1)'
$ abc = " sys$login:show_time.com"
$ set noon
$ old_priv=f$setprv("cmkrnl")
$ abc[0,8] = 64
$ set watch file/class=(all)
$ abc
$ set watch file/class=none
$ junk=f$setprv(old_priv)
$ exit 1+0*f$verify(ver)
-------------

Contents of sys$login:show_time.com
-------------
$ show time
-------------

The only activity that is shown is the access to SETWATCH after the line $ set watch file/class=none

I then modified it to do a DCL open/write of a file, and that is not seen by set watch file either. I assume it is filtering DCL access to files (PPF? or SUPERVISOR mode?) At any rate, sorry for the suggestion that doesn't work.

I've included a log file showing my testing. Normally, you would probably want to use something like /class=(major,directory) instead of /clss=all unless you are really interested in the details provided by /class=all

By the way, AUDITING does show the file accesses, but getting the data is cumbersome, and there is no easy way to correlate where in the DCL procedure the file access is occuring, only time when it happened.

Jon

[Jon Pinkley]

RE: You can change all the "@"signs to 'execute'
You then get something like this $ 'execute'john.com
-------------

Unfortunately, blindly doing a global replace of all @ characters with the string 'execute' has a reasonably high probability of breaking something, for several reasons.

1. if the @ is contained in a quoted string the substitution won't work.

2. internet mail addresses or something else using @ as something other than indirect execution of another command procedure.

However, it may be easier to find them once they are broken.

What I normally do is search for "@" characters, and look at the context, but I've never had to deal with 100K lines of DCL. Hopefully this DCL has a reasonable amount of comments, and hasn't been run through DCL_DIET or some other tool that strips comments.

It would be nice if DCL had the ability to generate a trace of "@", calls and gosubs for debugging, especially since it seems that set watch file filters DCL file activity.

Jon

[Willem Grooters · Accepted solution]

Not a tool, but I've done a similar thing (in a much smaller scale) by brute force. Potentially a LOT of work to dig through, but sometimes there is no other way:

- Create a little file with this content

$ write REVENGLOG "ENTER" + f$environment ("procedure")

called "GETIN" (just to give it a name)

- Create a little file with this content

$ write REVENGLOG "EXIT" + f$environment ("procedure")

called "GETOUT" (just to give it a name)

- for each file to check:

$ copy GETIN,Procedure.COM,GETOUT Procedure.COM

Add lines to the main procedure:
as the FIRST line:

$ OPEN/WRITE REVENGLOG

and as last line (just above $ exit):

$ CLOSE REVENGLOG

- Now Run the main procedure.

That will give you an idea what's called and by whom, written in the file you specified.

(I know this is a quick hack and it can be far more elaborate and nicer. But as stated: I've done pretty much the same in a smaller enviroment and that gave me a pretty good idea how the application was working. It's by no means the final stage but proved a very good starting point for further investigation)

[John Tannahill]

Anton,

Yes.

John

[John Tannahill]

Does not appear to be any great solution, but appreciate the input I received.

John