Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part four in a five part series of blog posts that will be highlighting a number of tools and techniques that will help you squash those bugs. If you missed part one, it can be found here. Part two can be found here. Part three can be found here. This installment helps you answer the question “Is my server code correct?”

Is my server code correct?

When working on web pages, to make sites as interactive as possible, you will often need code in at least two places. The server, which in this case would be the LANSA application server running on an iSeries or Windows box, and the client would be a miriad of browser types running HTML and JavaScript. The mixture of HTML (for presentation) and JavaScript (for interactivity) is a very strong match. It gives web applications the power and functionality that is often attributed to windows GUI applications.

RDMLX is the LANSA language that runs on the server. It is originally designed on BASIC structures and over the years has evolved into a very mature language that rivals all the big names like C++, Java, Etc. It is reasonably easy to pick up and be productive quickly, and can be ported to different platforms if required. When running LANSA WAMs websites, RDMLX is the code which is running on the server side. Development of the RDMLX code is done in a modern Visual IDE. This IDE has some great debugging features. The IDE is a window rich client application which runs on the developer’s PC, and allows the developer to “check-out” code from the server, to work on that code, and then to send it back to the server to run. Another great feature of this IDE, is the ability to debug code running on the server. This is the feature that we will explore in this article.

Architecture and Flow

1. The debugging process starts at the Browser. A URL is called which tells the server which WAM to run, to run it in debug mode, and where the IDE is that will do the debugging.
2. The server contacts the IDE, to have a 2 way conversation, passing back and forth the variables and the line which the server is currently executing
3. Using the IDE, you can set breakpoints, change variables, and step through the code to observe your application behavior.
4. Once the program has completed it’s tasks, the server sends the resulting HTML page back to the browser.

• All code actually runs on server
• All database IO occurs on server

Setup Steps

Some developers do not use this great capability because of the setup steps involved and possible complications. However, once you know what to check, setting up a debug session is a snap. Here are the steps that I always go through….the first time running a debug in a specific environment.

1. Your WAM needs to be checked-in/compiled with Debug turned on. Shown below is the check-in dialog box.
   
   
2. Check the current IP address of your development PC. The IBM I will use this IP address to contact the IDE to do the debugging. The IPCONFIG command can be typed into a dos window. Keep in mind that if you are on a VPN..you will need to be using the IP address from your VPN connection. You should be able to ping your PC from the IBM I.
   
   
3. Ensure that the debug setting inside the IDE are setup correctly, and on a port which the IBM I can use to connect to the developer PC. This dialog can be found in the IDE menu options/settings/debug.
   -If the debug does not work, you need to make sure that there are no firewalls between the IBM I and the developer PC that may be blocking port 51234 (default)….This includes the windows firewall.
   -When you first start, make sure that the “Break at first executable statement” checkbox is checked (this is to prevent confusion if the debug session never passes your breakpoints). As you get more advanced, you may start running debug from a different point.
   
   
4. The LANSA Server environment needs to be told that debug can be run. This should only be done only for the development environment. You can leave debug disabled for production. This setup step can be done in the LANSA Web Administrator tool which was used to setup your web environment. In this tool, you go to menu tools/configure systems/data-application server. Under the miscellaneous tab, you need to check the “Allow interactive debugging” checkbox.
   
   
5. Setup your breakpoints. These are point which will stop a debug so you can step from that point and inspect variable. Breakpoints can be set by putting the cursor on a line and pressing F9. Breakpoints show as a line highlighted in red.
   

Doing the Debug

Now that your environment is setup, you can step through the server side code of any WAM application. To start a debug, your WAM has to be compiled (with debug on) and checked-in to the server. Then you go to the design tab on your IDE, and press the magnifying glass.

If the setup is correct, you should get a debug session loaded in your IDE. You should be able to step through your code using F8 (step into). You can also use F5 to run until the code encounters a breakpoint. Inside the IDE, the yellow lines indicate what line in your program is about to be run, and variable values can be inspected on the left of the interface. Variable can also be changed…for testing purposes.

Remember to recompile your WAM with debug turned off once you have completed your work. Debug adds about 40% to the size of the code, and will likely make the code run slower.

This type of debugging can be a huge time saver when finding those nasty hard to find bugs. It allows the developer to notice any piece of code where the logic goes in the wrong direction, where unexpected values come out of files, or some typo causes your application to go down in flames. This is a tool which every Web developer should have in their arsenal.

In my next and final blog posts on this topic, I will be highlighting another tool and techniques to help answer the following questions:

• Am I passing the correct information between LANSA and the web page?

Andy

LinkedIn
https://plus.google.com/+AndyBain
@jandybain