Debugging Ideal/Web Applications

Products

• Datacom
• DATACOM - AD
• Ideal
• Datacom/Server
• Datacom/DB
• Datacom/AD

Issue/Introduction

The Ideal for Datacom interactive debugging facility can also be used to debug Web-based applications, but there are a number of considerations for its use in this environment.

 

Environment

Release: Ideal for Datacom

Resolution

Using a Test Driver

This method is appropriate only for applications that are invoked via GET and do not need an expanded (>32KB) response.

A simple top-level program is created to invoke the Web subprogram from a 3270 session, so that it can be treated by the debugger as a "regular" application. Starting a debug session on this program then provides the environment for setting breakpoints in the subprogram. An example is given below:

You can use this method prior to adding an entry to the SCWBTRAN table, as the Web driver is not involved. Most of the early demonstration samples were developed using this method.

The Web Debug Driver SC00WBDD

If the @I$ABOVE or @I$IPOST utilities are being used, this requires access to CICS data areas which would not exist with the test driver method above, so such programs need a different technique. This may also be the case with some SQL code, where cursors could be lost in an interactive debug session.

A driver program SC00WBDD is provided for use with web transactions that require DEBUG or DIAL processing. A revised analyzer handles the transactions DIAL and DEBUG by invoking SC00WBDD instead of the SC00WBTD that is usually employed for Ideal/Web transactions.

To use the debugger, the URL is changed to:

http://www.example.com:port/DEBG/uuu.mmmmmmmm/txid?parms  (www.example.com would be set to the server domain URL)

The uuu is a user id, and mmmmmmmm is a member name specifying the debugger commands. These are set up as for a batch execution, as there is no terminal upon which to display breakpoint data. Note that the debugger output is written to DBUGLIST for the user running the application, as specified by the SCWBTRAN entry for "txid", not the "uuu" user in the URL, who is the owner of the debug command member.

Just like for a batch run, the debugger assumes a GO at the end of each attachment. But unlike batch, there is no way to follow the DEBUG command with the definitions of the breakpoints, so these MUST all be placed in a member before you start.

The easiest way to set up a member for debugging is the same technique we suggest for batch:

• Issue the DEBUG command for any Ideal program (not necessarily the target of your eventual debugger run).
• When the debug commands member is displayed at the initial breakpoint, issue a PROC command specifying the program in which you want to set breakpoints.
• Use the AT line command to mark the lines.
• When all breakpoints are set, type QUIT RUN instead of GO.
• Add an attachment (typically LIST commands) to each breakpoint.
• You can now duplicate the DEBUG member to a new name, which you can use in the web debugging session.

Broadcom Support may need internal trace information from the DIAL facility to investigate problems with your applications. To use the DIAL facility for a Web program, the URL becomes:

http://www.example.com:port/DIAL/xxxxxx/txid?parms (www.example.com would be set to the server domain URL)

Where xxxxxx is the DIALMASK string (or ALL) for a SET RUN @I$DIALMASK command that precedes the RUN of the Web application. These are enclosed by @I$TRACE ON LOCAL and @I$TRACE PRINT commands, so that an OUTTRACE output will be produced, again for the user in SCWBTRAN.

The DIAL and DEBUG transactions are set up as alias transactions, just like any other Ideal/Web applications, but they do not need entries in SCWBTRAN. The transaction being debugged must have one, of course. The transaction identifiers are fixed in the SC00WBTD code and cannot be changed.