Debugging T24

TEMENOS T24 Debugging T24 Server 'How To' Guide

User Guide

Amendment History:

Revision

Date Amended

Name

Draft

July 2006

Alex Leggett

Initial version

1.1

January 2007

Tony Porter

Browser debug section

1.2

February 2007

Description

Add jBASE environment variable setting and Dave Gearing additional example for $ variables.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV. Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Debugging T24 Server 'How To' Guide Table of Contents TEMENOS T24 ......................................................................................................................................1 Debugging T24 Server 'How To' Guide..................................................................................................1 User Guide.............................................................................................................................................1 Executive Summary................................................................................................................................3 Support...................................................................................................................................................3 Debugging Options.................................................................................................................................4 Using the Debugger in T24.....................................................................................................................7 Useful RAID Debugger Commands......................................................................................................11

TEMENOS T24 User Guide Page 2 of 15

Debugging T24 Server 'How To' Guide

Executive Summary This document gives a brief introduction to the methods which can be used to track down logical and data-related errors in T24. This mainly concerns the use of the ‘RAID Debugger’, a command-line tool used for debugging jBASE routines at runtime; and Visual Debugger, which is based on the RAID Debugger. The use of SEAT, JOB.TIMES and other useful files are also discussed here.

Support Technical Issues with RAID Debugger – eg commands not working – consult jBASE support Technical Issues with Visual Debugger and all other issues – eg not displaying source code – check TTS and create Service Report as necessary



Debugging Options The approaches taken to track down errors in an application can vary almost as much as the types of problem found. However, some of the most useful general approaches are given here. While it may be tempting sometimes to start from the beginning of the application and step through the code line by line, this can be a time-consuming and frustrating approach. In many cases, it will lead to the debugger becoming out of step with the source code after some time due to the large number of called routines in T24 and the necessity of compiling routines in your account in order to be able to debug them. T24 Upgrades deliver the object code in pre-compiled libraries ‘globusbin’ and ‘globuslib’, and unless these are recompiled the RAID debugger can sometimes lose track of which line in the source code matches the object code being executed. A better approach is to try to identify the likely areas that could be causing the problem, and to look at the state of all relevant variables. This could be done either by manual intervention using a debugger or by adding debugging code in which data is written to a log file. This is best done using a straightforward jBASE ‘WRITE’ statement, rather than calling F.WRITE as you are not then subject to the vagaries of caching and will therefore be guaranteed to see the current data appearing on file now. Once analysis of the data has been carried out, it will still often be necessary to look at the sequence of code execution via a debugger (either the RAID debugger or Visual Debugger). The way this is used within T24 depends on what you are trying to debug.



Finding the problem If the problem is happening during validation of record entry, then the best place to start to look is during the CHECK.FIELDS and/or CROSSVAL stages of processing. The diagram below shows the process flow for the standard T24 Template:

Enter Application Check ID

Is Message = 'VAL'

Define Parameters Read Record Just Parameters?

Yes

Yes

If Function = 'D'

NO

Yes

No

Is Message = 'AUT'

Terminator

Is Message Repeat No

If Function = 'R'

Yes

Call Matrix Update

Yes

Call Matrix Alter

Check Reversal Initialise

Check Record

No Yes

Main Program Loop

Check Delete

Process Display

Get Function/Record ID

No

Mesagge Loop No

is Message 'RET'

Yes

No

Input Mode?

No

Auth Cross Val

Overrides

Before Auth Write

Before UnAuth Write

Call Auth Write

Call UnAuth Write

After Auth Write

After UnAuth Write

Yes

New Function?

Field Input

Field Display

Yes Has Message been set

Check Function

Is Function 'E' or 'L'

Cross Val

Field Navigation Loop

Terminator

No Yes

Call Function Display

No

Is Message = "ERROR"

Check Fields Yes Increment Field Position Field Navigation Loop

No Mesagge Loop

Main Program Loop

Template/GOSUB Yes External Subroutine

Figure 1 Flow-Chart showing Execution of the T24 Template Note that there are some older applications within T24 that do not follow exactly the same logic. They also may not have the FIELD.DEFINITIONS, CHECK.FIELDS, CROSSVAL or OVERRIDES functionality separated into separate subroutines. If you are not sure what is happening, and T24 appears to ‘hang’ then it may be useful to use the Spy Session on T24 DevStudio to examine the last request and response as a starting point. Also, always check to make sure that the object code being executed belongs to the source code you THINK has been compiled. In order to check what is being run, use the ‘jshow’ command. For instance, to see what version of FX.CHECK.FIELDS is running, enter: jshow –c FX.CHECK.FIELDS



Problems with Versions are often due to APIs attached to the Version within the following fields: •

AUT.NEW.CONTENT – Routine to automate field entry

•

VALIDATION.RTN – Routine to validate a field

•

INPUT.ROUTINE – Routine run on commit of record, before file writes (pre-authorisation)

•

AUTH.ROUTINE – Routine run on authorisation of record

•

ID.RTN – Routine to validate item-id

•

CHECK.REC.RTN – Routine to control field attributes

•

AFTER.UNAU.RTN – Routine run on commit of record, after file writes (pre-authorisation)

•

BEFORE.AUTH.RTN – Routine run on authorisation of record, before file writes

•

WEB.VAL.RTN – Java EB.API record routine to validate on Web Server

Problems with enquiries are usually due to APIs attached to the enquiry. The fields containing these are: •

BUILD.ROUTINE – the routine which builds the enquiry data

•

ENQUIRY.NAME – the drilldown

•

CONVERSION (when field content prefaced with ‘@’) – post-processing of raw data from file

Note that there may also be I-Descriptors in the Standard Selection record, which invoke jBASE routines.



Using the Debugger in T24 Debugging Applications in T24 is fairly straightforward, and can be done using either the Visual Debugger or the RAID debugger. If you are debugging ‘Classic’, it is simply a matter of setting a DEBUG statement wherever it is required and then waiting until you hit it. You can also, of course press to invoke the debugger at any time. Debugging standard T24 using browser, however, requires a little more initial work.

Setting up Visual Debugger In order to use Visual Debugger, you will need to have installed T24 ToolBox and set it up correctly (see the T24 Setup, T24 ToolBox and T24 DevStudio ‘How To’ Guides). If TCServer has been running since before the DEBUG statement was inserted into the code and the code compiled, it should be ‘reset’ to ensure that it picks up the latest version of the object code. The Visual Debugger should be started before the application is launched, so that it is listening before the DEBUG statement is hit:

Figure 2 Visual Debugger waiting for a DEBUG condition TEMENOS T24 User Guide Page 7 of 15


Setting up a Debugger Session If you would prefer to use the RAID Debugger rather than the Visual Debugger, you will need to set up a TELNET session which points to the debugger port. You must also have the following environment variable set in your unix profile, export JBASE_DEBUG_PIPE=1 As with Visual Debugger, you will need to ‘reset’ the TCServer after compiling the code containing the DEBUG statement, otherwise TCServer will not see it. The TELNET session should be configured so that the Server is the same as the server on which TCServer is running, and the port number matches the debugger port. The debugger port is displayed when TCServer starts up: Starting deamons ... - Admin Console started on port - Debugger deamon started on port - Spy deamon started on port - Telnet deamon started on port

: : : :

50780 50782 50783 50781

In this case, since TCServer was started up on Dev-Pseries1, all that needs to be done is to create a new TELNET session, pointing to Dev-Pseries1 port number 50782. If the TELNET session is correctly set up and pointing to the debugger port, it should look something like this:

Figure 3 Debugger Session



Debugging Jobs in the Close of Business The Close of Business processing in T24 can either be run automatically or in debug mode (sometimes referred to as ‘interactive mode’). See the COB ‘How To’ Guide for further information. In order to debug Close of Business it must be run COB in debug mode, with a limited number of agents set during the debugging process. Note that this can be done by setting the WORK.PROFILE field of the TSA.SERVICE COB record to the preferred TSA.WORKLOAD.PROFILE:

Figure 4 Changing the number of agents while COB is running Note that once a DEBUG statement is hit, the output of the RAID debugger (and the input) will happen in the window of whichever tSA(s) hit the DEBUG statement. The tSM will also declare the agent to be ‘dead’ after a certain time and will keep prompting you to start up another agent. Obviously if you are still debugging, that agent is still active, and starting up another agent to pick up its thread may confuse the issue!



Debugging Browser Related Issues Due to issues with the Visual Debugger, this is not recommended for general use by the browser team. Use instead a Reflections session on the debug port, as shown in the Setting up a Debugger Session. As soon as a debug statement is hit in the Browser, a debug prompt will be displayed in the Reflections session. Be aware that you can’t backspace or use your cursor keys – so be careful of starting with the letter ‘c’ by accident. Also when debugging using this method the first 2 prompts in the telnet session will not work, see below, so hit return twice on initial entry to the debugger. Temenos Connector BASIC Debugger V1.3.2_14 DEBUG statement seen Source changed to /storage1/globus.accounts/globus.acc.1/david.gearing/dgdevb/dgdevb.run/BP/REPO 0628 DEBUG jBASE debugger->W ûÿW !! ûÿW -- command is not available jBASE debugger->W W !! W -- command is not available jBASE debugger->W W 0624 0625 *----------------------------------------------------------------------0626 CHECK.RECORD: 0627 * Validation and changes of the Record. Set ERROR to 1 if in error. 0628 DEBUG 0629 IF R.NEW(RP.RECORD.STATUS) = 'IHLD' THEN ; * CI_10045763 s 0630 GOSUB CLEAR.CHILD.TXN.IDS 0631 END ; * CI_10045763 e 0632 IF R.NEW(RP.CALCULATION.LINK) = '' THEN ;* EN_10000956 S jBASE debugger->

To see the XML being passed to the browser, put a DEBUG at the top of OFS.REQUEST.MANAGER and view the THE.MSG variable.



Useful RAID Debugger Commands Caveat: Some of these commands are not supported in Visual Debugger. At the time of writing this document there is no official list of supported RAID commands for the latest version of the jBASE RAID Debugger, however this document will be updated when such details become available.

Command Syntax Command

Explanation

!command

Spawn another process and execute the command. The previous command thus used can also be recalled and executed by the !! command.

Display the next 11 lines of source in the current file.

Nn

Set the current display line to line nn in the current file and then display the line. Note that the program execution counter remains unchanged, it is only the display pointer that is changed. A command such as s (see later) will correctly execute the next line in the programmed sequence, not the newly displayed line.

B

Display all currently active breakpoints.

b {-t} nn{,file}

Set a breakpoint at line nn in the current file or that specified by the file modifier. If the -t option is specified then the breakpoint will cause a display of all the trace variables rather than halting the program.

b {-t} varname

This form of the b command will cause the debugger to be entered whenever the contents of the specified variable are changed.

C

Continue execution of the program.

d {-tbed} {*nn}

Delete breakpoint and/or trace table entries, and will normally prompt for confirmation. The t and b switches refer to trace and breakpoints respectively. The * switch deletes all of the specified entries without prompting. The nn switch deletes the entry nn in the given trace or breakpoint table, also without prompting. The d and e switches respectively disable or enable the given entry without removing it from the table.

f {on|off}

A debug breakpoint is set for a filename change. This break can be set to on or off. If the program is continued (C command) the debugger will be entered the next time the source file changes.

j {-g}

The j command displays a complete history of both GOSUB and external subroutine calls. When issued without options the command will only display information about the current program or subroutine. The -g (global) option will show a breakdown of the entire application.

p {pathlist}

Defines the list of directories and pathnames (delimited by :) that the debugger will then search to find source codes. p without a pathlist displays the current Path.

s {-t{m}d} {nn}

Continue execution of jBC code in single line steps before returning to debug. The value nn changes the number of lines executed before returning to debug. The -t switch is used to display the trace table after every line executed, rather than wait for entry to debug. The d switch sets a delay before executing each line of code. m is used to set the delay in seconds (default is 5 deci-seconds).

S {-t{m}d} {nn}

Same as c except this will 'step over' subroutine calls, the code within the


Debugging T24 Server 'How To' Guide subroutine will not be displayed. T

Display the current trace table.

t {-fg} expr

Add the value specified by expr to the trace table. When debug is entered, all the values in the table are displayed. The f switch is used to fully evaluate expr, whilst the g switch extends the display of expr to all levels.

v {-gmsrv} {expr}

Evaluate expr and display the result. The effects of the switches are: g to extend the display of expr to all data areas. m to allow variable modification within expr. When a variable is modified with the m option binary characters may be entered using the octal sequence \nnn. The sequence \010 would therefore be replaced by CHAR(8) in the modified variable. The sequence \\ evaluates to the single character \ and a sequence such as \x evaluates to the single character x (i.e. the \ will be lost).

w nn

Display a window of source code. The default is 9 lines with 4 before and after the current one. The value nn is used to change this parameter. Table 1 Debugger Commands

Debugger Redirection and Pipes The debugger provides the ability to redirect the results of its internal command set to a file or through a pipe to a command. This is a very powerful feature of the debugger. The following commands allow this feature: V

Display Variable(s)

H

Display History Trace

B

Display Breakpoints

T

Display Trace Table

Here are some examples of this feature: Syntax

Description

v | pg

Pipe through the pg filter

t > tracetable

redirect trace points output to file

v Record > file

Display variable contents to a file Table 2 Debugger Redirection



Execution - Single Stepping s{-tcgd{n}}{nn} Argument

Description

-t

display trace table after each source line executed

-c

only count the lines of source in the same CALL level

-g

only count the lines of source in the same GOSUB level

-d{n}

enter a delay in increments of 100 milliseconds between executing lines of source. This is incremented by the n value entered.

nn

execute the next nn lines of source before re-entering debug Table 3 Single Stepping Arguments

This command is used to execute the program in steps and to re-enter debug after the execution of a given number of lines of code. Traced variables are displayed after debug is re-entered, and any screen display within the executed code is shown as normal. Entry

Result

s

The simplest form of the command executes the next line of the code and then re-enters debug.

s –t

The next line of code is executed and the contents of all entries in the trace table are shown.

s -t4

The next four lines of code are executed displaying the trace table entries before re-entering debug.

s 20

This command executes the next 20 lines of code before re-entering debug.

s -td5 200

The command executes the next 200 lines of code. The -d switch sets a delay in increments of 100 milliseconds between each line executed. The 5 denotes that a 500 millisecond, or half second delay is set before executing the next line. The default value is 1, or 100 milliseconds. The -t switch ensures that the trace commands are shown after the execution of every line. While this process is continuing, debug can be entered by breaking into the program as normal. This is a very useful command to use when a run-time error occurs in a program, and the area of code responsible needs to be found quickly. With the -d switch set, it is also possible to speed up or slow down the execution of the code if the initial value chosen is too fast or slow. This is done by entering a number from the keyboard in the range 0-9, which alters the delay to the given number of 100 milliseconds increments.

s -d3t 500

The command will execute the next 500 lines of code with a delay factor of 300 milliseconds between each line. The speed of execution can be increased or decreased by pressing the numbers 0-9 on the keyboard during execution. In addition to this, the -t switch means that the contents of the variables trace table will be displayed after every line of code executed. Table 4 Examples of how to use single-stepping arguments



Variable Display V{-gvmrs} Syntax

Description

V ANS

The simplest form of the command will display the contents of the variable next to the variable name, in this case ANS. This will only produce a display if the source is at level 1, or in the home directory. If the variable has not been assigned, the value (NULL) is displayed. If the value assigned happens to be null, however, then a blank (null) will be displayed next to the variable name.

v -g ANS

If the variable in question resides in a different data area to the local level (COMMON or NAMED COMMON), then the -g switch should be used to display the variable contents. This extends the display of the variable to data levels, and is particularly useful when executing a subroutine in a sub-directory or library.

v -m ANS

The -m switch displays the variable and contents, but in addition allows the user to modify the contents. An equal sign is shown after the variable contents, and any characters or numbers entered followed by a carriage return are taken to be the new value of the variable. Entering a carriage return leaves the variable contents unchanged. The character sequence \nnn is replaced by the binary character defined by the octal number nnn. Therefore the sequence \376 would be replaced by a field mark.

v -gv ANS

This command displays the value held in variable ANS no matter what the current level of the source. In addition, the -v switch shows the type of variable (string or numeric), its memory location, and size.

v -r NAME

This command displays the contents of the variable NAME at the start of the next line. The -r switch provides a raw character view of the variable name and value.

v -s NAME

The -s switch shows a short view of the variable being the first 128 bytes. The * and ? characters can also be used within the variable name as wild card characters. The ? denoting a single occurrence of any character, and the * denoting any number of occurrences of any character. Table 5 Displaying Variables in Debugger


Debugging T24 Server 'How To' Guide The table below shows some examples: Entry

Result

v A*

displays all variables beginning with the letter A

v A???

displays all four letter variables beginning with the letter A

v *-INV

displays all variables ending with the characters -INV

v *ENP*

displays all variables with the characters ENP within their name

v LIS(2,*)

displays every element in the second row of the dimensioned array LIS

V V\$FUNCTION

Displays contents of the common variable V$FUNCTION, note the $ must be prefixed by \ otherwise the $FUNCTION is interpreted as an environment variable. Table 6 Examples of Displaying Variables

All the above tables are taken from the jBASE knowledgebase which contains further commands for the debugger. http://www.jbase.com/knowledgebase/index.html


Debugging T24

Recommend Documents