Simple debugging of CA Gen mainframe runtime modules - F40069

Idea created by flm on Oct 16, 2015
    Under review
    Score13

     

    Gen runtime is a blackbox. In case of errors involving runtime modules, it is very difficult for Gen users to locate runtime errors. We cannot access any logs from the given runtime modules, so we can get any help to locate the errors. What we need is a very simple log function, which shows the following information:

     

    • Which runtime modules call each other (CALL STACK)

     

    • Runtime version number and compile time

     

    This simple information will speed up the time we use for given CA Support information about our installation and error situation. CA Support has to ask about 100 questions, to locate something useful about our error situation. It takes very long time, and is a big waste of time. I’m sure that CA Support will appreciate the solution too. This solution is very simple and very quick to prepare. I know that CA is considering this: Enhance debugging of mainframe applications, if customers vote for this. I think we also need this solution, but if I know CA well, it will take a lot of years to prepare this, because it is more complicated. What we need now is a very quick solution, because we are in deep **** with the CA runtime modules. 

     

    I will give these examples.

     

    Example 1.

     

    Our installation has gone wrong, and we have got a mix of different runtime modules. It is difficult to locate without looking in the log with the CALL STACK.  

     

    Example 2.

     

    When using new runtime (8.5), we can see that our application now call a function in a runtime module, which CA has removed. Here it is very important to locate which module trying to call the removed function, because it is stopping our upgrade. In this case (after 8 month), I discovered that if I got a newer PTF level, the problem disappeared. I’m sure that the CALL STACK would have rectified this problem immediately, and have spared me for an 8-month delay.  

     

    Please vote for this solution ASAP.