On Mon, Apr 17, 2017 at 3:46 PM, Bill Woodger <[email protected]>
wrote:

> John, you are after a general API to allow "something" to have a
> meaningful impact on code-generation by the (Enterprise COBOL) compiler?
>
> I think we've had a "non-denial denial" (or similar) that there is a
> single API for EXEC. Even if similar (who knows?) they are different. Each
> interacts directly with its target sub-system (CICS, DB2, IMS).
>
> I think they are "asking what your sub-system can do for you"-type, rather
> than "this is what you can do with the compiler if you set this, that and
> the other". Use of a DB2 API, rather than being an API to the COBOL
> compiler (I can be very wrong there).
>
> If they were intended to be open to ISV use, they'd be documented as a
> "Vendor Interface". If they were so exposed, then there'd be "constraints"
> on what could be changed in the compiler ("you can't do that, it'll break
> XYQ product").
>
> There is, of course, nothing which stops anyone writing a "pre-processor".
> It can also be "integrated", such that it does not require a separate step,
> using an "input exit". Any processing which may be analogous to the
> integrated processors would be done in the exit, and the "already
> COBOL-ified" code is what would be presented to the compiler.


​Thank you. That is an excellent idea. I actually use such an input exit
with HLASM called FLOWASM. It allows me to write HLASM code in "free
format". So much for my "wild & crazy" thought. Today has just been "too
Monday" for me to cope with well.​


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to