COBOL does not seem to have anything like the PL/1 preprocessor. Or even the <shudder/> C preprocessor. Hum, I guess it would be possible to use the C preprocessor despite not having a C license. I don't know if it will run or not. In any case, this sort of preprocessor is not what I would really _love_. I would _love_ to get hold of the internal parse tree and be able to modify _that_. But I get quite strange at times.
On Tue, Jun 4, 2013 at 2:02 PM, Bernd Oppolzer <[email protected]>wrote: > 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 > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
