Topic
  • 6 replies
  • Latest Post - ‏2013-08-27T12:20:35Z by markevans
navana
navana
22 Posts

Pinned topic EGL 8.5.1.0 - ELAE Abend in CICS

‏2013-08-26T12:32:40Z |

Has anybody had any problems with ELAE abends in the CICS region with EGL generated to COBOL CICS? Previously everything was fine(code was generated with 8.0.1.1). Now we have recently migrated to higher version of RBD ver 8.5.1.0 and changed few interface's and generated the same with DEV, FST, UAT.

Code works fine without any issues in FST and DEV. But the same code fails in UAT CICS with ELAE abend. When looked at the Rational cobol TDQ(ELAD) shows the error message as attached.

When searched "ELA00032P" called program %%% received a parameter list which is not valid. But the same thing worked perfectly fine with FST and DEV.

Someone else faced this sort of issue or any clue why this is behaving like this? Please suggest.  Thanks in advance.

Attachments

  • Hsieh
    Hsieh
    600 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-26T13:16:27Z  

    Hi Naveen,

     

    Did you test in EGL Debug ? 

    I saw that you started the program using CICS Mirror Transaction (CSMI).

     

    Hsieh

  • navana
    navana
    22 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-26T15:00:11Z  
    • Hsieh
    • ‏2013-08-26T13:16:27Z

    Hi Naveen,

     

    Did you test in EGL Debug ? 

    I saw that you started the program using CICS Mirror Transaction (CSMI).

     

    Hsieh

    Hi Hsieh,

    This CICS program is being triggered by a Web service function. This Web Service function is present in a EAR, which is deployed in WAS 7.0.0.23(Same version applicable for FST and UAT).

    In Dev, I am using WAS 7.0.0.25 for EGL 8.5.1.0. The deployed version HTML (IHS) -> invokes the web services (WAS) -> which triggers this CICS Program(CICS CTG).

    As I don't have the authorization to test the code present in UAT region, I haven't debugged that. But in Dev region, I am able to debug this and works fine as expect.

    Thanks

  • Hsieh
    Hsieh
    600 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-26T15:38:51Z  
    • navana
    • ‏2013-08-26T15:00:11Z

    Hi Hsieh,

    This CICS program is being triggered by a Web service function. This Web Service function is present in a EAR, which is deployed in WAS 7.0.0.23(Same version applicable for FST and UAT).

    In Dev, I am using WAS 7.0.0.25 for EGL 8.5.1.0. The deployed version HTML (IHS) -> invokes the web services (WAS) -> which triggers this CICS Program(CICS CTG).

    As I don't have the authorization to test the code present in UAT region, I haven't debugged that. But in Dev region, I am able to debug this and works fine as expect.

    Thanks

    It seems the program MCM001M not have same parameter length.

     

    Maybe you could get in ELAD extrapartition transient data ELAXPRNT queue or intrapartition transient data queue more detail error message to investigate.

    The MCM001M is EGL program ?  tried to regenerate.


    Hsieh

  • markevans
    markevans
    2807 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-26T21:56:37Z  
    • Hsieh
    • ‏2013-08-26T15:38:51Z

    It seems the program MCM001M not have same parameter length.

     

    Maybe you could get in ELAD extrapartition transient data ELAXPRNT queue or intrapartition transient data queue more detail error message to investigate.

    The MCM001M is EGL program ?  tried to regenerate.


    Hsieh

    Hi,

    As Hsieh suggested, I would double-check that the MCM001M program in UAT is the same as the one you have in the other stages.  The check that causes the error message is pretty simple.  When the program is generated, it calculates a length for the expected commarea.  then it checks at runtime if it received that many bytes.  If they are not equal, then this message is issued.

    I use CEDX on the tran id to see how many bytes are being passed...and if you have the generated COBOL, look for EIBCALEN in the program and see what it is expecting.  These should match.

    The usual causes are linkage table inconsistencies in the area of:

    a.) parmform = COMMPTR or COMMDATA

    b.) remotePgmType = EGL or ExternallyDefined

    Remember that the calling and the called program must be genned to the same specifications.

     

    One note, when remotePgmType=EGL is used on the calling side, an extra 16 bytes is passed to the called program.  If that program is generated as a "local" call, then it is not expecting this 16 bytes and you will get the message.   Sometimes if the called program is shared between calls local within CICS and as a remote call, you don't want these extra 16 bytes to be passed.   So, just set remotePgmType=ExternallyDefined and it will still call the program, but just not pass the extra 16 bytes.

     

  • navana
    navana
    22 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-27T11:12:47Z  
    • markevans
    • ‏2013-08-26T21:56:37Z

    Hi,

    As Hsieh suggested, I would double-check that the MCM001M program in UAT is the same as the one you have in the other stages.  The check that causes the error message is pretty simple.  When the program is generated, it calculates a length for the expected commarea.  then it checks at runtime if it received that many bytes.  If they are not equal, then this message is issued.

    I use CEDX on the tran id to see how many bytes are being passed...and if you have the generated COBOL, look for EIBCALEN in the program and see what it is expecting.  These should match.

    The usual causes are linkage table inconsistencies in the area of:

    a.) parmform = COMMPTR or COMMDATA

    b.) remotePgmType = EGL or ExternallyDefined

    Remember that the calling and the called program must be genned to the same specifications.

     

    One note, when remotePgmType=EGL is used on the calling side, an extra 16 bytes is passed to the called program.  If that program is generated as a "local" call, then it is not expecting this 16 bytes and you will get the message.   Sometimes if the called program is shared between calls local within CICS and as a remote call, you don't want these extra 16 bytes to be passed.   So, just set remotePgmType=ExternallyDefined and it will still call the program, but just not pass the extra 16 bytes.

     

    Hello,

    Issue resolved now, its not related to CICS, its related to WAS. Recently there was a migration happened for existing UAT server which triggered this issue. As the deployed EAR(old one during the migration) was mentioned as root, its not considering the new EAR, always points to the older EAR from root.

    In the older version of EAR, we have the interface length as 142 but it was changed as 136 and generated to CICS. So, WAS triggers this CICS call with 142 as interface length but it was different in the CICS. Because of that ELAE in CICS.. :(

    Now this was changed as wasuser and updates to EAR is now properly reflected and application works as is.

    Thanks

    Attachments

  • markevans
    markevans
    2807 Posts

    Re: EGL 8.5.1.0 - ELAE Abend in CICS

    ‏2013-08-27T12:20:35Z  
    • navana
    • ‏2013-08-27T11:12:47Z

    Hello,

    Issue resolved now, its not related to CICS, its related to WAS. Recently there was a migration happened for existing UAT server which triggered this issue. As the deployed EAR(old one during the migration) was mentioned as root, its not considering the new EAR, always points to the older EAR from root.

    In the older version of EAR, we have the interface length as 142 but it was changed as 136 and generated to CICS. So, WAS triggers this CICS call with 142 as interface length but it was different in the CICS. Because of that ELAE in CICS.. :(

    Now this was changed as wasuser and updates to EAR is now properly reflected and application works as is.

    Thanks

    Glad to hear it was resolved.