Good initiative, but I doubt the usefullness.
The big problem with DCL programming is not invalid labels and if-then(-else)-endif constructs because these are clearly identified by DCL itself. Undefined symbols, unopened files are not a big issue either.
You'll find these when testing - which _should_ be done before a procedure is put into production.
No doubt that software, checking on these issues, can be useful. Foremost on big, lengthy procedures. But since DCL itself can take care of that, I think it's usability limited. I tried DCL_CHECK once, it did a good job but simply failed the major bug in the procedure I was working on at that time.
Mispelled logical names, and, foremost, symbol names, or local.vs. global assignements are a far greater concern because typo's are easily made and overlooked, especially in large, complex procedures:
$ dev1=""
$ avoid="TRUE"
...
$ devl=="some value"
$ aviod=="FALSE"
...
$ dev1=="something"
...
$ if avoid
$ then
$ if dev1 .eqs. "" then ....
...
Searching for a reason of unexpected, or errenous behaviour can be a tedious task in such an environment. If your procedure is capable of picking these out, then it's really useful.
WG
Willem Grooters
OpenVMS Developer & System Manager
