An EGL Web Service is using a direct CALL to call an another existing CICS non-EGL program using CICSOSLINK..  With a direct call, the called program

is not expecting a channel from the calling program . However when the called  program does a EXEC CICS ASSIGN CHANNEL, it gets a  CHANNEL DFHAC-V1.

Is this normal or is the calling EGL program not really using CICSOSLINK?

The EGL CICS Web services uses Channels, so given this is a dynamic COBOL Call, could it be picking up the channel from that.

Assuming you are using linktype=dynamic, parmform=CICSOSLINK, then it should not be expecting a channel to pass the parms, but that does not mean there is not one known to the transaction.

If you send the webservice source to us or the generated .cbl for the service, we can easily see if the called program is using a channel when calling to non-EGL.

Thanks Mike. Just thought I might update you.  You were right. i set up a trace and found that the calling program,being a web service,  sends the web service related channels, even with a direct call.

Thx for letting me and the forum know what you found.

Were you able to accomplish what you were looking to do?

I managed to modify the called program  to check for this particular channel and perform processing accordingly,

Hi,

I took a deeper look at this.  

If I understand correctly, your scenario is this:

MyService (EGL Service) -> Calls -> PGMA (non-EGL).

If this is correct, when I generated the service and used PARMFORM=CICSOSLINK and LINKTYPE=DYNAMIC, then the parms are not passed via a Channel.   The are passed as "using" variables which means the receiving program would need to expect the EIB, the Commarea, and then the record (or fields) that are being passed in its Procedure Division.     See the code below:

Since the service DOES use channels as the vehicle to send parms to it, I would expect an ASSIGN to still return a value, but the called non-EGL program does not need to deal with it if I understand things correctly.

Generated code for call statement to non-EGL program passing "myrec".

     * EGL *9* Call "PGMA"(myrec);
           MOVE "PGMA" TO EZEPROGM
           PERFORM EZESETUP-CALL
           MOVE 9 TO EZEAPP-PRC-NUM
           SET EZERTS-CALL-CICSOSLINK TO TRUE
           SET EZERTS-DYNAMIC-CALL TO TRUE
           MOVE EIBCALEN TO EZEWRK-TALLY0
           MOVE EZEWRK-TALLY TO EIBCALEN
           CALL EZEPROGM
                USING DFHEIBLK DFHCOMMAREA (1: EIBCALEN) MYREC-6
                ON EXCEPTION
                   MOVE EZEWRK-TALLY0 TO EIBCALEN
                   MOVE "00000001" TO EZERT8
                   MOVE 9 TO EZERTS-PRC-NUM
                   MOVE "CALLPROGRAM-FFGAA" TO EZERTS-PRC-NAME
                   PERFORM EZE-THROW-INV-EXCEPTION
           END-CALL

Hi,

You are absolutely correct. When the  non-EGL program is called by a EGL Web Service on a direct call, it gets the EIBAREA and a COMMAREA.

This particular called program tried to determine whether user data was passed in the COMMAREA or a Channel. It does this by  using EXEC CICS ASSIGN to get a Channel. In this  case the called program got the DFHAC-- channel  on the ASSIGN, which is not actually a user data channel and wrongly assumed it was a user data channel. I modified the called program to assume data is passed in the COMMAREA if the DFHAC channel is found.