Problem of Hexa Values for Decforms

[IT Resource Center Foru_3]

Hi All,

We are working on an application which uses Decforms for user inputs(i.e we enter some values on screen fileds). Once of the screen field has been defined as Character(3). When we give any of charecters like " " * , ! , @ , # , $ , % , ^ , & , ( , ) " and some of the mnemonic like "SOH, ETX ", etc then it will work fine. But if any Hexa decimal values like "X2A for +" is given then we are getting a error like ..

%FORMS-E-PROC_ESCAPE_ERR, request terminated due to severe error in procedural escape routine

Here I have copied a part of trace where the error triggerd :

Begin collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
End of collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Procedural escape signalled the following error:
%FORMS-E-PROC_ESCAPE_ERR, request terminated due to severe error in procedural escape routine
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000000000, PS=0
Returning receive control text "EI031".
End request.

Begin DISABLE request.
Begin Initialize request phase.
Validate the arguments for this request.
End Initialize request phase.
Begin External Response phase.
Begin external responses for this request.
Begin interpreting default response for this request.
End default response for this request.
End external responses for this request.
End External Response phase.
End request.



"-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000000000, PS=0
Returning receive control text "EI031"."

When I compiled I did not find any errors or warnings.
I followed the following steps to get the trace :
DEFINE FORMS$TRACE "T"
DEFINE FORMS$TRACE_FILE "my directory"
DEFINE/USER SYS$INPUT SYS$COMMAND

--
even I tried with error logs using the following command:
DEFINE FORMS$LOG_EVENTS "T"

I have also attachaed the EVENT_LOG file. So if any body has the idea how to solve these type of problems and how to find which escape routine was failed, please let me know how to solve.

Regards
-KSSR

[Volker Halle]

KSSR,

did you read the DECforms Programmer's Reference Manual's chapter

2.3.7 Enhancements to Escape Routine Debugging

about the FORMS$DEBUG_ESCAPE_ROUTINES logical ?

Volker.

[Volker Halle]

for reference:

same question as in

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1336656

Volker.

[IT Resource Center Foru_3]

Hi Volker,

I have alredy tried the thing which you have specified. But I did not get any extra information if compare with my earlier trace file.

Here I have set "define FORMS$DEBUG_ESCAPE_ROUTINES "T" " in my current session. and started the normal image once, then Form Manager did not call the debugger, then I set the same value and run the debug image, then also i did not find any extra things from the earlier one.

any how I will provide you more details from trace file:

Save_tpa is one of the procedure call which will be called from forms like :
Begin CALL response step for procedural escape SAV_TPA.
Begin collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
Collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
End of collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
---
--
Begin collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
End of collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Procedural escape signalled the following error:
%FORMS-E-PROC_ESCAPE_ERR, request terminated due to severe error in procedural escape routine
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000000000, PS=0
Returning receive control text "EI031".


in case of success:

Begin CALL response step for procedural escape SAV_TPA.
Begin collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
Collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
End of collecting record field TPA_F_PARTNER_ID from form data item TPA_F_PARTNER_ID.
---
---
Begin collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
End of collecting record field TPA_F_I_SECURITY_QUAL from form data item TPA_F_I_SECURITY_QUAL.
Begin distributing record field TPA_F_PARTNER_ID to form data item TPA_F_PARTNER_ID.
Distributing record field TPA_F_PARTNER_ID to form data item TPA_F_PARTNER_ID.
End of distributing record field TPA_F_PARTNER_ID to form data item TPA_F_PARTNER_ID.
---
---
Begin distributing record field TPA_F_I_SECURITY_QUAL to form data item TPA_F_I_SECURITY_QUAL.
Distributing record field TPA_F_I_SECURITY_QUAL to form data item TPA_F_I_SECURITY_QUAL.
End of distributing record field TPA_F_I_SECURITY_QUAL to form data item TPA_F_I_SECURITY_QUAL.
End response step.



-Regards
-KSSR

[Volker Halle]

KSSR,

did you read that chapter in the manual ?

Just defining the logical won't do any good. You need to use this mechanisum to enable you to set a break point in your procedural escape routine...

Maybe this routine isn't even defined ? PC=VA=0 could point to a call to an undefined entry point.

Volker.

[IT Resource Center Foru_3]

Hi Volker,

If simply defining FORMS$DEBUG_ESCAPE_ROUTINES macro is not the thing that i have to follow, then I am understing the following things :
-----
To invoke the Debugger, you must link the executable image that calls the
Form Manager with traceback.
--
Here I have two things one is normal exe, another is debug exe.
So I have to normal exe or debug exe?, and what is the traceback here.
-----

Once the Form Manager invokes the Debugger, you must enter the appropriate
SET IMAGE, SET MODULE, and SET BREAK debug commands to set up a
debugging environment. A GO command is also required. The SS$DEBUG
condition is signalled as close as possible to the actual CALLG instruction that
invokes the escape routine."
--
Where I have to keep the break points here?
-----

I have already debugged the code by keeping break points ar Sav_tpa function which again calls many sub routines, but if i check the return values of all sub routines form this function, they all are fine and returning success.

after the success of this routine the control again going to FORMS_TRANSCEIVE() request, then hangs here.

- KSSR

[Volker Halle]

KSSR,

you need to run the debug-version of the DECEDI$INTERCHANGE.EXE file. It must have been linked with LINK/TRACE.

According to the documentation: 'If you specify the logical name FORMS$DEBUG_ESCAPE_ROUTINES as true, the Form Manager invokes the Debugger by signalling SS$DEBUG the first time an escape routine is called for a given DECforms session.'

You trace file show the call stack and there is a FORMS$MANAGER routine address at the top of the stack. I believe it is quite likely, especially as the ACCVIO happens with VA = PC = 0, that the entry point is undefined.

Based on the name of the image you're trying to debug, you seem to be working for or at HP. Maybe you can find someone around you, who has some more experience using the debugger and OpenVMS troubleshooting techniques.

Volker.

[Volker Halle]

KSSR,

do you know about the SET BREAK/EXCEPTION debugger command ? This may help you to automatically get at the debug prompt if an exception is being signalled.

Then work backwards through the instruction stream and call stack to find out, where any why this exception is being generated.

Volker.

[Hoff]

I posted some pointers to information on how to debug this stuff (debugger, an ACCVIO, and a pointer to the documentation on how to get into the DECforms stuff for debugging) over in the other thread.

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1336656

The brute-force solution is some variation of a breakpoint on an exception, or the truly ugly STEP and SHOW CALLS, STEP and SHOW CALLS, and repeated until the SHOW CALLS fails. Or a desk-check for subroutines and descriptors that are returning data into a stack-based buffer. Or some combination.

It's probably now time for another programmer to stare at this code for a while, and see what is writing zeros up the stack; the trigger for what looks like a classic buffer overrun. Another set of eyes has been known to be seriously helpful at spotting these sorts of errors.