I'm trying to move a custom applicaton from an older to a newer system. The old system was 7.1-2 and it still runs. The "new" system is openvms 7.2-1. According to the applicaton developer this version should be ok. This was about the last version when they stopped development.
What happens is that I have a print queue with a custom symbion attached that is producing a crash dump and stopping the queue. This crash dump cannot be read by the analyze utility. The dump utility also does not show anything exiting about the dmp file. From what I understand, the queue prints to NL: and the symbiont it supposed to take the print item number and send it to the applicaton.
I have compared the running system with the new system and don't see the difference. Are there some other utilities that I could try to find out what goes wrong?
With which command did you try to analyze the process dump ? What is the exact error message ? Please provide the information as an attached .TXT file.
Try $ RUN/DEBUG symbiontname. If the DBG> prompt show up, enter EXIT. If not, post the error messages.
In general, describing what you want to do is o.k. when done in general words, but for failing commands and error messages, you should supply them EXACTLY character by character !
The only think I have done so far is to use $ana/crash nw2smb.dmp which results in %SDA-E-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha system dump
The other thing was the dump utility, which shows hex/text of the file, but I could not make out anything useful.
SYSTEM@NW2>anal/image/header nw2smb.exe does not show me anything useful either.
I have attached a text file describing the problem and showing the info I have.
Maybe I'm missing some library or logical which causes the symbiont to fail. It is still running on the old machine, but I cannot find the difference to the current setup.
The NW2SMB executable was linked in July 1997, so I'm guessing the application move was by copying the executable rather than installing on the new server? Might be worth doing a new install of the app on the 'new' server, see if it links a new executable for you.
Is the file NW2SMB.TLB in sys$library: ?
You have an access violation, which means you are trying to access an area of memory you are not allowed to. Can be caused by many things, but root cause is often something else entirely, which (down to bad programming not checking for an error!)subsequently results in an attempt to access memory location zero.
Have fun, PJ
Have fun,
Peejay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If it can't be done with a VT220, who needs it?
>>> The only think I have done so far is to use $ana/crash nw2smb.dmp which results in %SDA-E-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha system dump <<<
Try ANALYZE/PROCESS_DUMP. For that version of VMS SDA could not read/understand process dumps.
I spend a good portion of last night to verify the old running system with the new one, again. No additional files, no logical or symbols seems missing. There are no .tlb files in sys$library, but also not in the old system. The "dba:21" entry in the /parm of the queue is actually a reference to the "database" file. I verified the reference and also checked file permissions, including disk and directory. I was missing W:E on the root directory, but it did not make difference.
It is a complex system. Everything else seems to work fine, except the symbionts. Could it be the difference between ovms 712 and 721? Perhaps something like a "trace" utility that could be used to track the applicaton while its running might show the point where it fails. I tried $run/debug NW2SMBSRV.exe and then typed "SET TRACE/BRANCH/CALL". I was guessing something might show up when the error occurs, but it does not show anyhting. I guess I don't know how to use it or attach to the symbiont.
Problem solved. Recreating the configuration document for the symbiont solved it. Apparently there was something in the document, maybe invisible character or empty lines it did not like. For some reason it did not affect the older production system. Files were moved using the backup /save_set utility.
