Operating System - OpenVMS
1748201 Members
2907 Online
108759 Solutions
New Discussion юеВ

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

 
SOLVED
Go to solution
Hein van den Heuvel
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Well that's all odd/fun.

btw... the status in the $set watch log shown is hex:
$ exit %x910
%SYSTEM-W-NOSUCHFILE, no such file

but that's probably reflecting on the lines just before that.

Odd, how a sortmsg can touched or not.

Are the paths through (sy)login.com exactly the same?
Toss in a $SHOW TERM/FULL, and maybe a $SHOW LOG/PROC, $SHOW LOG/JOB ?

fwiw,
Hein.

Volker Halle
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Art,

did you produce a process dump ? This should at least tell you, in which piece of software the ACCVIO is happening (PC=0EE3298). And what's on the call statck at that point of time.

Volker.

Art Wiens
Respected Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

The app is compiled/linked with debug and I found the source. I've traced it as far as I can and have included the output. I also traced it with a working Telnet session and it just moves past where the Decnet session fails. Google hasn't turned up much on FDV$DTERM.

Art
Hein van den Heuvel
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Hi again Art,

I'm afraid I can not try just now, but I would guess that FDV$DTERM (Detach Terminal) is reacting to a bad 'TCA'.

I'd check the return status on the FDV$ATERM (attach Terminal) for the both situations.
It may have failed. Of course that's no excuse for DTERM to ACCVIO, but it may help your quest.

btw... odd for a program to mix direct screen IO (Escape sequence to line 24) and FMS calls.


fwiw,
Hein.
Hoff
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

FDV$DTERM is part of the rundown processing for DEC FMS.

Something has romped on the stack, or there's an exit handler messed up, the TCA has been sat upon, etc.

http://h18000.www1.hp.com/support/asktima/appl_tools/0090948E-B0A673E0-0801E7.html

Art Wiens
Respected Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

I found in the source where FMS is initialized:

FMS::FDV$Status_l = FDV$ATERM( FMS::TCA, ! Terminal Control Area &
"5000"L, ! Size of TCA &
"1"L) ! Logical I/O Channel number
if FMS::FDV$Status_l <> FDV$_SUC ! FDV status code
then Print "FDV$ATERM failed ";FMS::FDV$Status_l;" in ";PROGNAME;VERSION;RELEASEDATE;BEL
Exit Function

ie. it checks the status after it sets it up and doesn't fail there. I looked at FMS::TCA and it doesn't seem to change value during or after the failure.

DBG> dump fms::tca
-1776 17661952 4236 .........├Г┬╣.. 00000000006643F9

Hoff, I read that article you gave ... although not an "exhaustive" analysis on my part, but the variables seems to be different in the various functions.

I did go back to the v7.2-2 system and tried it ... works fine by Telnet or Decnet. The code is circa 1985 and doesn't look like it's been touched since 1992 ... how long can a bug be "dormant"?! 15 years I guess! ;-)

I should just hand this over to "the programmers" but I'm not sure they won't be back at my desk shortly thereafter. What else can I check for? (and how?)

Cheers,
Art
Hein van den Heuvel
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Art,

That looks like relatively solid BASIC/FMS coding judging by the clear type casting and such. Still, stuff can slip in.
The size '5000' is a little suspect. I don't think I've ever used anythign but '12'. The AWKSP yes, there a larger vale helped avoiding re-allocations.

I now recall issues with this set of calls, way back when (1991!) at that time resulting in 'Illegal String Class Error' on program 'end', but it was triggered by FDV$DTERM being passed a bad/stale TCA and it just went with it, corrupting variables on the stack. This sort of thing could easily be version dependent.. is random stack addresses are used at time point.
Andd ACCVIO is only a bit away from illegal string so to speak.

The TCA and WORKSPACE are arrays of 3 LONGwords, or 12 byte strings passed by descriptor. The contents is 'opaque', but the data must ofcourse stay valid. A static variable is most save. You can use (dynamic) strings, but they must be pre-extended to the 12 bytes.
Looks like a record structure is used.
You may want to doublecheck the details.
You may want to doublecheck 'option type=explicit' is in effect.

From the FMS manuals:
"The locations for workspace, terminal control area, run-time
memory-resident form area, and status recording variables
must all continue to exist while the Form Driver is using
them. They must remain allocated until the workspace and
terminal control area are detached, until forms in memory
location are deleted, and until the status reporting variables
are no longer used. Protect the variables by placing them in
a common storage area; otherwise, the compiler might place
them in dynamic storage."

http://www.sysworks.com.au/disk$axpdocjun042/progtool/dyy4aaa6.bkb

http://www.sysworks.com.au/disk$axpdocjun042/progtool/dyy4aaa6.p109.bkb

ATERM FDV$ATERM (tca.ml.da,size.rl.r,channel.rl.r[,trmnal.rt.dx1 [,faketrm-
typ.rt.dx1[,options.rl.r]]])

good luck!
Hein.
Hoff
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

{{ how long can a bug be "dormant"?! 15 years I guess! ;-) }}

For as long as the code is old, technically.

{{ I should just hand this over to "the programmers" but I'm not sure they won't be back at my desk shortly thereafter. What else can I check for? (and how?) }}

The trigger in that support article was stuff messing about within the TCA, intentionally or otherwise. A stack bug can, for instance, slam other storage (such as the TCA) on the stack. An IOSB that gets written to storage no longer allocated, etc.

I'd first review the whole of the code, and add explicit error checking throughout. Then head off after any asynchronous processing and the associated coding errors that can lurk. There exists a list of some of the more common coding errors over in topic (1661) of the old Ask The Wizard area. If things get weird, start looking for subtle and latent errors, and by solidifying the code.

Volker Halle
Honored Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Art,

you might want to use DBG> DUMP/LONG to make sure, you see all the binary data in the TCA area.

Volker.
Art Wiens
Respected Contributor

Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure

Hey ... 10 points for me!! Look what I found:

http://ftp.support.compaq.com.au/pub/patches/vms/axp/v7.1/fms/2.4/decfmseco5024.README

It mentions a couple of cases where ACCVIO's can occur, none match my scenario "exactly" but worth a shot.

It looks like our FMS installation was the original FMS v2.4 ie. no patches applied.

I installed the patch and tried the app a few times Decnet and Telnet ... no crashes on exiting! Hopefully it's "fixed" now.

Thanks all for the help/advice, learned quite a few things along the way - never used the debugger interface before - never looked at the app's mainmenu source before.

Cheers,
Art