Nenad,
Thanks for the additional info.
You are partially correct.
First, you are correct in that you can specify/use different linkage entries based on the program being called. And they can be different ways of being invoked..
So, you would use a linkage entry as you described for ABCCHN1 to tell the generator that it should expect to receive parameters through a Channel/Container.
On the others, I would just let ALL use the defaults which would be a dynamic COBOL call and passing pointers. My view is to not create entries unless you need to as you then have less to maintain.
Second.
There is a still an issue on the channels/containers in relation to the MQ bridge. When you specify parmform=Channel, we generate code that expects the data to be passed a specific channel name and container name as listed below from the EGL Generation Guide:
CHANNEL parameter format
For the CHANNEL parameter format, containers are passed in a channel. A channel is a set of containers that function like parameters for passing data between CICS programs. No COMMAREA is passed in the CHANNEL parameter format.
When an EGL generated program passes a channel to a called program, the channel has the same name as the called program. However, when an EGL called program receives a channel, the program uses a CICS API call to retrieve the name of the channel that was passed.
The containers are named EGL-PARM-1 through EGL-PARM-n, where the maximum value of n is 30.
On reading the CICS/MQ doc, the channel/containers used are container DFHREQUEST in channel DFHMQBR_CHANNEL on entry and container DFHRESPONSE in channel DFHMQBR_CHANNEL. The linked-to program must use these names.
So, there is a mismatch in names. I don't know of a way to override the generated EGL names for Channels/containser, so I see a couple of choices:
a.) Write a native COBOL routine whose only function is to get/put the container and then call out to the EGL program with the data.
b.) Do the same in EGL, but use the new "execute #cics" capability in EGL (as of 9.0.1, 9.1, or 9.1.1) to issue the GET/PUT container requests.
To use the "execute #cics", you could do something like the code sample below (also attached). If you go with this example, it probably does not matter if you generate with a linkage table or not as the handling of the Container/Channel is hard coded, not generated.
And the call to "caldpgm" would be a dynamic cobol call.
NOTE... I have not tested it, but the generated code looks correct.
// basic called program//program DEFCHN1 type BasicProgram() {} dfhrequest dfhrequest; dfhresponse dfhresponse; rec5 rec5; function main() // get info from the container execute #cics{GET CONTAINER("DFHREQUEST") CHANNEL("DFHMQBR_CHANNEL") INTO(:DFHREQUEST)}; // do work and call out to local program move dfhrequest to rec5 byName; call "caldpgm" (rec5); move rec5 to dfhresponse byName; // put info into the container execute #cics{PUT CONTAINER("DFHRESPONSE") CHANNEL("DFHMQBR_CHANNEL") FROM(:DFHRESPONSE)}; endendrecord rec5 type BasicRecord 10 fld1 char(100); end record DFHREQUEST type BasicRecord 10 fld1 char(100); end
Here is the generated code for the "get":
* EGL *12* Execute #cics{GET CONTAINER ("DFHREQUEST") CH ...
* EGL *12* ANNEL ("DFHMQBR_CHANNEL") INTO ( :DFHREQUEST ...
* EGL *12* )};
DISPLAY "* 12: Execute #cics{GET CONTAINER ('DFHRE ..."
EXEC CICS
GET CONTAINER ("DFHREQUEST") CHANNEL ("DFHMQBR_CHANNEL") INTO
( DFHREQUEST-4 )
END-EXEC
Let me know if there are follow-up questions/comments.
Mark
markevans