With PL/1, for example, many of the things you want can be done IMHO
using the PL/1 preprocessor facility. We use it for example to enforce some
site rules, for example: some PL/1 statements which must not be used at
our site. The macro statements which do this are included in a startup macro
which is at the beginning of every program. Of course, there are ways to
compile programs without this, but you will not be able to get such a
program
into production through the home grown change and config system.
In addition, we have a separate tool called PLIRULE, which parses the
PL/1 source much like a compiler, does syntax and semantic checks
(looks for possible runtime errors doing some static analyzes), and
enforces some site rules which cannot be enforced using the technique
mentioned above. This can be called from the ISPF editor window
directly (while editing), but it runs with every compile, too.
Don't know much about COBOLs COPY ... SUPPRESS, but:
maybe it is cheaper for you to do what you want, if you write your own
preprocessor, which preprocesses all your sources just before the
compile (and resolves the COPY statements in the way you want them
to be resolved).
I think, I would do it this way.
There is no "real" macro processor in COBOL, IIRC?
Maybe it would be a nice challenge to add one?
Kind regards
Bernd
Am 04.06.2013 20:30, schrieb John McKown:
I known that most, if not all, of the IBM compilers have exits which allow
a person to supply or modify both input and/or output records. I have used
this with a freeware program called FLOWASM for HLASM, which allows "free
form" assembler statements. What I am wondering is if anybody would really
like something that has occurred to me. Instead of receiving and modifying
input _records_. I would like to get a tokenized input _statement_. That is
something "further down the line". Why? Because I sometimes need to modify
a _statement_, but I need to look at the entire statement, not just a
single record. Receiving a tokenized (parsed) statement which I could then
modify would make some things much easier. One thing that I could use right
now is a way to "nullify" the SUPPRESS phrase if it is on a COBOL COPY
statement. The SUPPRESS phrase makes the compiler output unusable to the
Compuware post processor program. And we must use that because the version
of Compuware we have (and have no support for) does not support invocation
via CA-Endevor release 15. At least it doesn't work correctly and
CA-Endevor support indicated that it is likely a Compuware "problem". But I
can envision some other "interesting" things that it could be used for.
Such as enforcing some in house "you must" or "you must not" rules on
programmers who may not be aware of all the issues.
Any consensus as to how desirable this might be, in general? Or am I out in
the left field parking lot again?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
