Re: slow debug

Warren,

I had several people speed up their RDI debug by doing two things...

1.) Do NOT leave the view "Variables" open all the time, or active
It has a high overhead cost, since it can monitor every variable in your Old Monolith-code...
(Assume you are in the main-line, not a sub procedure)
It greatly improved my co-workers debug performance, when he no longer left that window ACTIVE. I have it open all the time, but usually have my Monitor View the active pane in my debug group of views... (Monitors/Breakpoints/Variables/IBM I Service Entry Points)
NOTE: It is fine to use the view "Variables" in your sub-procedures

2.) If you have tons of saved break-points, it might be a good idea to clear your saved break points once in a while...
I often am debug the same programs, and love being able to remember break points. But, if you have over 1,000 saved break points, I bet your performance can be downgrade significantly...

Following those two steps, my debug response is normally quite zippy!

You might want to have your system administrator tune the work-area where RDI runs. My compiles are typically much faster than my green screen compiles...

When more people started using RDI, it seemed to slow down. But, then the Administrator did some tuning, and adjusted some shared memory pools, and we got excellent performance!
Not sure exactly what he did, except he had said he added additional memory allocated. I am sure your system administrator should know about that!

Now, my initial startup time is approx. 5-20 seconds. But, after started, it seems to go fairly smooth for me!

But, we also have an AWESOME system administrator who knows his stuff too!!! <Big Smile>


-Ken Killian-

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Warren Schultz
Sent: Monday, March 24, 2014 11:37 AM
To: wdsci-l@xxxxxxxxxxxx
Subject: [WDSCI-L] slow debug

Can the creators of RDI please work on getting debug to work faster? That is a big complaint from the folks @ my shop. Some get that "Engine is busy" error, though I personally have not. If you have a source member of any size, you'd better be ready for a long coffee break. Compiles could run faster too. If you want to wean folks away from SEU/PDM, then those basics need to be addressed.

Thanks

Warren S. Schultz
Senior Systems Analyst
American Foods Group, LLC
500 S. Washington St.
Green Bay, WI 54301-4219
Phone: 920-436-6472
Fax: 920-436-6551
Email: wschultz@xxxxxxxxxxxxxxxxxxxxxx<mailto:wschultz@xxxxxxxxxxxxxxxxxxxxxx>
[AFG_logo_signature]