- 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-21-2007 11:45 AM
тАО12-21-2007 11:45 AM
Environment:
- ES47 model 4, 8GB memory
- VMS v7.2-2 restored from an existing Alpha 800, 512MB memory
- Upgraded to v7.3-2, all VMS patches applied
I tried one of the applications (written in BASIC v1.3 and uses FMS v2.4 screens). I am able to launch the app and navigate it's menues, choose a function that I have a bit of familiarity with and inquire/retrieve a record ... all seems to work fine. Trying to exit the application (Gold PF1) the process gets an ACCVIO (see attached).
Is there anything that can be gleaned from this little bit of info? Is there anything I can do/try from a VMS perspective? I don't have access to the source code to answer any such specific questions.
Cheers,
Art
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-21-2007 12:44 PM
тАО12-21-2007 12:44 PM
SolutionThose addresses do not mean much ot anyone.
The very least you need to provide/consider is some crude memory map.
And I would also run once with $SET WATCH FILE/CLA=MAJOR. It is not unlikely to be an environment / file problem
$SET PROC/NAM=TEST
$SET WATCH FILE/CLA=MAJOR
$RUN program
:
! manoeuver around, untill just before exit
! Watch for errors in set watch output all along
^Y SPAWN ! Or second window
$ANAL/SYSTEM
SDA> SET PROC TEST
SDA> SHOW PROC/CHAN
SDA> SHOW PROC/IMAGE
SDA> EXAM/INSTR interesting-address-from-accvio - 40 ; 80
Does SDA in 7.3-2 have LNM TRACE?
Again, just in case it is environmental and the access happens to try a logical name use that.
LNM LOAD
LNM START TRACE
Back to main window and try the exit.
LNM STOP TRACE
LNM SHOW TRACE (filter for the right PID)
Good luck!
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-21-2007 07:54 PM
тАО12-21-2007 07:54 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
I doubt if something like this has anything to do with your OS upgrade. It is probably an application level bug. So there's no way you can recompile and relink that particular program with debug?
$ basic/debug/noopt
$ link/deb
If there is an option file? This may not be the exact syntax for recompiling and relinking on your system, just a general suggestion.
Otherwise, I think those SDA suggestions are very informative and useful. I think though at some point, you want to be able to get access to source code or somebody who does have access to source code and solve the problem that way.
Another thought, you might want to check the process quotas, if they changed with the upgrade. Do you have a copy of the operating system before the upgrade you can fall back on to see if you still get this error? And you can check for any changes in quotas?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-21-2007 07:54 PM
тАО12-21-2007 07:54 PM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
On zero evidence, my first target would be for an error in a declared exit handler ($dclexh), or something in the main exit path. But again, a reproducible error is a wonderful thing.
And no, it's not clear if this a bug introduced in the upgrade, or a latent bug in the application. My bet would be on the latter.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-22-2007 12:19 AM
тАО12-22-2007 12:19 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
issue a SET PROC/DUMP and then run your program. Once it will ACCVIO, you'll get a process dump written. Consider the run with CMKRNL priv set, so that you get all of of the process address space and important parts of system address space dumps.
$ ANAL/PROC imagename.DMP
DBG>
You can now debug the failing isntruction, you can invoke SDA (from the DBG> prompt type SDA) to look at the images activated in the process and the channels and have all the information you need - except direct mapping of adresses to source code lines.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 02:49 AM
тАО12-24-2007 02:49 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 02:59 AM
тАО12-24-2007 02:59 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
you're right. Running the image (creating the process dump) with CMEXEC prevents the following error message:
%SDA-W-EXCLDATA, data excluded from dump due to insufficient privilege
when trying to analyze the process dump with SDA.
Merry Christmas,
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 06:01 AM
тАО12-24-2007 06:01 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
What I've found is that the problem only occurs if "the user" is an RTA device ie. a Decnet session (SET HOST 0) which is what I was doing on Friday. If I Telnet in, it works fine. Something changed in Decnet IV in VMS 7.3-2?
I will continue the investigation.
Cheers,
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 07:50 AM
тАО12-24-2007 07:50 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access SORTMSG.EXE;1 (2232,3,0) Status: 00000001
%XQP, Thread #0, Control function (2232,3,0) Status: 00000001
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0009, PC=0000000000EE3298, PS=0000001B
The Telnet session does not access this file - other than that, all other accesses are the same.
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-24-2007 08:08 AM
тАО12-24-2007 08:08 AM
Re: VMS upgrade v7.2-2 to v7.3-2 - subsequent application failure
Exit and error handlers are sensitive to these sorts of subtleties, and ASTs can encounter similar sensitivities.
Errors that move are errors that involve uninitialized values, or stack values, or race conditions, unsynchronized completions or other such.