On Mon, Apr 17, 2017 at 2:30 PM, Allan Kielstra <[email protected]> wrote:
> I wouldn't necessarily assume that there is a fixed API for EXEC CICS, > EXEC SQL, EXEC SQLIMS. It's always possible that each one of these gets > some sort of custom treatment from the compiler. > Of course, that is possible. And it may be why an API is not documented. You can't document that which doesn't exist. I would consider it to be a bit short sighted, but likely easier (and so cheaper) to implement. I believe that the co-processors themselves are _not_ distributed with the COBOL product, but with the other product (CICS & DB2 in my initial post). Mainly because of the error message that I got when I tried, just for fun. But I guess there could be some "hanky panky" going on between the compiler writers and the co-processor writers. Or maybe the compiler writers write the co-processor and give it to the appropriate product team to distribute. I suppose that, if I were really curious, I could do a GTF trace of a COBOL compile to see what modules it tries to LOAD/LINK to. And then use one of those names to "preempt" the functionality, just to see what is happening. Nothing like doing a nice S0C1 abend with a SYSMDUMP to do some "looking around". -- "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
