Idea Details

Simple debugging of CA Gen mainframe runtime modules - F40069

Last activity 06-13-2019 10:03 AM
flm's profile image
By: flm
10-16-2015 06:15 AM

 

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. 

 


Comments

02-08-2017 04:19 AM

Hi Rob.

 

Both good and bad news.

 

The main problem is the runtime modules. In step one, you can forget all about actions blocks and procedures. If we just get a callstack of the used runtime, where we can see the compile and link time, we (and CA) will get simple and useful information. Here we just need a debug flag, to activate the callstack. Then you can forget problems about performance issues. My suggestion and hope is that we get the simple debug very quickly, because it is so simple to implement. Afterwards you can make the complicated debugging of CA Gen mainframe runtime modules<https://communities.ca.com/ideas/235726478?commentID=233950865&et=watches.email.idea_comment#comment-233950865>.

 

Hope you understand what I write, and I'd love to deepen my thoughts on this subject, if necessary.

 

 

Venlig hilsen

 

Flemming Mølgaard, Senior Infrastructure Architect

 

SCE Platform & Betaling

 

Lauritzens Plads 1, DK-9000 Aalborg

E-mail flm@kmd.dk  Web www.kmd.dk<http://www.kmd.dk>

Direkte +4544602473 Mobil +4522694870

 

 

Fra: Rob_T

Sendt: 7. februar 2017 18:30

Til: Mølgaard.Flemming FLM <FLM@kmd.dk>

Emne: Re:  - Simple debugging of CA Gen mainframe runtime modules

 

CA Communities <https://communities.ca.com/?et=watches.email.idea_comment>

 

 

Simple debugging of CA Gen mainframe runtime modules

new comment by Robert Thompson<https://communities.ca.com/people/Rob_T> View all comments on this idea<https://communities.ca.com/ideas/235726478?commentID=233950865#comment-233950865>

02-07-2017 05:53 PM

By the way, the total number of unique votes (between this and the duplicates) for this idea is 18 at the time of this update 

02-07-2017 12:28 PM

We have introduced the beginnings of an internalized trace facility in Gen 8.5-8.6, and intend to expand it further in time. Currently the data is only available in a dump for internal use, but the plan is to add additional entries and data and format that information upon abend using a Language Environment trap. A debug summary would be written to the appropriate print destination. There is a tradeoff here between performance and information gathered, since this type of facility must run with every transaction to be available for unpredictable events and abends. Therefore we code for minimal footprint (both storage and CPU), making it somewhat more complicated than it sounds.

 

This will not be part of IR2, but it is being considered for IRs within this release.

 

Currently a standard stack trace will be produced by an LE dump, but that only includes modules called at the current level.

 

- Rob Thompson

11-02-2015 06:03 AM

flm We have an existing product that can provide the visibility I think you're seeking (APMConnect).  By default this product filters out all the calls to the CA runtimes, however we have a version available that makes these visible.  For additional detail drop me an email to tim.dargavel@response-systems.com. Cheers, Tim