- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent appl...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 08:11 AM
тАО12-24-2007 08:11 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-25-2007 12:12 AM
тАО12-25-2007 12:12 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-01-2008 06:34 PM
тАО01-01-2008 06:34 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-01-2008 09:11 PM
тАО01-01-2008 09:11 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-01-2008 09:22 PM
тАО01-01-2008 09:22 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2008 12:13 PM
тАО01-02-2008 12:13 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2008 05:55 PM
тАО01-02-2008 05:55 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-02-2008 06:51 PM
тАО01-02-2008 06:51 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2008 12:47 AM
тАО01-03-2008 12:47 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
you might want to use DBG> DUMP/LONG to make sure, you see all the binary data in the TCA area.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-03-2008 01:30 PM
тАО01-03-2008 01:30 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
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
- « Previous
-
- 1
- 2
- Next »