DECFORMS error on Receive

[Hitesh Rawal]

I am trying to execute a DECForm (COBOL) on VMS and the US (update screen program) successfully calls the ER (Escape Routine) and I can see that IO processing is occurring (CTRL-T).

Unfortunately the application terminates without displaying any results. The prgram is logging an error in an error file :

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

The Trace File displays the following error:

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

-SYSTEM-F-SUBRNG, arithmetic trap, subscript out of range at PC=0008D2F3, PSL=03C00000
Returning receive control text "EI031".
Can anyone explain what is going wrong here. I suspect it to be environment config as opposed to data issues. the application works in the production environment.

Is there any definitive documentation on setting up a DECForms environment?

Regards
Hitesh.

[Hein van den Heuvel]

Is this the first/only Procedural Escape function in the application?

Is this an old VAX application or native Alpha? (I ask because there was an old note I ran into which mentioend specific compile/vest options: COBOL/NOOPT/TIE/NOLIST
VEST/NOFEED/NOOPT/PRESERV=ALL/INTER=ALL )

Anyway, This error is very generic. The TRACE FILE normally has details. You already provided some details (SYSTEM-F-SUBRNG), but maybe there is more context in the trace to help you?

So could it simply be a 'subscript out of range' ? Are you using arrays? Could a subcripts be uninitialized/wrong?

The only 'environment' is the opportunity to 'find' the executable with the exacpe procedure in it (LIB$FIND_IMAGE_SYMBOL). Are the images/logicals in the rigth place during productions?


If this is the first PE, and you are using way old documenation, the there is a way old (1.4) Release note that might apply:

"2.3.3 Error in FORMS$ENABLE Vector-address Parameter
Chapter 4 of the DECforms Guide to Programming lists the passing mechanism for the vector-address parameter of the FORMS$ENABLE call as "by reference." The parameter should be passed by value with the parameter being the FORMS$AR_FORM_TABLE symbol or 0 (zero)."


How about the image linking? Clean? No errors? Check a link MAP to make sure the modules you expect to be there are in fact there?



Good luck,
Hein.

[Hitesh Rawal]

Thank you for this information. I will go back and investigate based on your suggestions.

A lot of this is very new to me.

If I get it resolved I will get back to you.

Many thanks again,
hitesh

[Hitesh Rawal]

Hello Hein

We are running DECforms v2.1 and is VAX.

I have recompiled and relinked everything.

FORMS TRANSLATE for the form
Compiled the US and ER files (only one Escape Routine).
Linked both with the Form.

I now get the following error: 14009042, which still causes the application to fail.

I know it is running my programs as the I have inserted DISPLAY statements and these are displayed as expected.

The program does check for a status of 14008522, which it assumes to be OK. Does 14009042 mean subscript out of range?

Regards,
Hitesh

[Hein van den Heuvel · Accepted solution]

Did you get a trace file going>

14009042 in decimal = %x 00D5C2D2 which is that %FORMS-E-PROC_ESCAPE_ERR

14008522 dec = 00D5C0CA = %FORMS-E-TIMEOUT

I'm still leaning towards a programming error involving array subscripts.
Can you compile COBOL/CHECK=BOUNDS ?


I did find a few more reference to this message PROC_ESCAPE_ERR.
1) out of quota. (it work for skem users, not for all)
2) out of local stack. What is the default for V2.1? A stack of 100 would allow you to pass about 50KB of data. NOTE: You must supply the stack size item list for EVERY DECforms request that may initiate the escape routine. Just putting it on the ENABLE request will not do the trick for other requests. FORMS$K_STACK_SIZE only applies to the current request.

Good luck,
Hein.

[Hitesh Rawal]

Yes I did get the trace file going ... (attached). the trace file doesn't really sdhow anything after the subscript out of range error.

I agree with you that there may be an issue with the arrays and this is a program level issue. I have compiled the program and receive a number of warnings (truncation issues).

These warnings are present in previous versions of the code and the code does work on a production machine. Hence it may be to do with the STACK.

I am going to fix the cobol warnings and see if this works first before doing anything with the STACK.

Regards,
Hitesh.

[Hein van den Heuvel]

Sounds like you might be using a good cunk of the availabel stack space judging by:

DETAIL_GROUP(100).DETAIL_LINE.
End of collecting record field DETAIL_GROUP.DETAIL_LINE from form data item DETAIL_GROUP.DETAIL_LINE.
Begin collecting record field DETAIL_COUNT from form data item DETAIL_COUNT.

SO there are 100 detail lines, @100 bytes each? and 16 month records @50 bytes?

I would focus on the DETAIL_COUNT value on entry into the PEU, making sure it is in range 1 to 100, not 0.

Just guessing...

Hein.

[Hitesh Rawal]

The DETAIL-COUNT starts at 0, so I believe this is OK.

The screen display four columns of 16 detail records. There is a side issue that prevents any more that 16 records being displayed. Page down just goes to the 16th record.

How about if I reduce the DETAIL-GROUP to 16 records to see if that has any impact? I can then work at increasing this.

Many thanks for your help with this. It is hugely appreciated.

Regards,
Hitesh.

[Hein van den Heuvel]

Hmmm....

From the trace...


Begin collecting record field DETAIL_GROUP.DETAIL_LINE from form data item DETAIL_GROUP.DETAIL_LINE.
Collecting record field DETAIL_GROUP(1).DETAIL_LINE from form data item DETAIL_GROUP(1).DETAIL_LINE.
Collecting record field DETAIL_GROUP(2).DETAIL_LINE from form data item



Sure looks to me that the file detail_group().detail_line element is numbered 1, not 0.

Hein.

[Hitesh Rawal]

Sorry Hein, I am getting a bit confused here.

In a previous message you mention:

I would focus on the DETAIL_COUNT value on entry into the PEU, making sure it is in range 1 to 100, not 0.

You then state:

Sure looks to me that the file detail_group().detail_line element is numbered 1, not 0.


Are you in agreement with me, that it does in fact start with 1 and not zero and that this is coreect?

I think some of the problems are down to compilation/linkage. I have compiled and linked the COB and forms having reduced the detail-line array to 16, however the trace file still shows 100 detail records being retrieved?

Do you have a step by step procedure for compiling and linking these forms IFDL files , Escape Routines, etc. I am using some existing command procedures but have a feeling that the object files for the ER is being written to the wrong library.

Regards,
Hitesh

[Hein van den Heuvel]

Sorry Hein, I am getting a bit confused here.

>In a previous message you mention:
>Are you in agreement with me, that it does in fact start with 1 and not zero and that this is coreect?

Yes, but earlier YOU wrote: "The DETAIL-COUNT starts at 0, so I believe this is OK."

I did not agree with that or did not understand that.



>>> I think some of the problems are down to compilation/linkage. I have compiled and linked the COB and forms having reduced the detail-line array to 16, however the trace file still shows 100 detail records being retrieved?

Ah! Now we are getting somewhere. If the program uses 16 and the form expects 100 then something is going to break, and it did.

> Do you have a step by step procedure for compiling and linking these forms IFDL files , Escape Routines, etc.

Sorry no, It's been too long. I seem to recall stuff like:
FORMS TRANSLATE x.IFDL
FORM EXTRACT OBJECT/VECTOR_ONLY x.FORM
or was it /NOFORM_LOAD ?

Isn't the PEU in an shareable library?
Is the shareable library build from an object library?
If so then you'd need two intermediate replaces:
recompile form and replace in object library
recompile shareable and move to execution directory.

I suppose that confusion in (shareable)image locations and/or object(library) location could easily explain how it works on one system and not the other.

Hein.

[Hitesh Rawal]

Hein,

Apologies, I did say it started at 0, I meant 1. Sorry.

I am going to take a good look at the evnvironment and command procedures and see if I can establish the link libraries, etc.

If I get anywhere with this I will let you know.

Thanks again,
Hitesh.

[Hitesh Rawal]

I have made some progress based on your suggestions.

Having compiled and linked all modules, I was able to debug the Escape Routine and discovered that the ER was in fact trying to write outside the array bounds.

I amended the code and have now resolved the subscript out of range error.

I now need to address the issue of displaying blocks of 16 records at a time. If I have any difficulties I am sure you will hear from me again!!

Many thanks for your help.

Best regards,
Hitesh

[Hitesh Rawal]

All good.

I now have a scrolling region of up to 64 items and have a good understanding of how to add additional items if required.

Have also got up to speed with defining function keys, etc.

Many thanks for all your help.

Regards
Hitesh.