Kbase 12783: Access violations and S/E 49 VMS servers Virtual Terminals
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Access violations and S/E 49 VMS servers Virtual Terminals
If a customer receives access violations and memory violation error
49 with 6.2L+, please check the following:
Was the access violation on the SERVER or the CLIENT. You can check
this by looking in the log file. After the time stamp there will
either be USR or SRV. If it is USR, then a client had the access
violation. If this is the case, please follow the regular procedures
for access violations and error 49 resolution.
If it is SRV, then the server had the access violation. They should
UPGRADE TO 6.2N12 or higher, AS SOON AS POSSIBLE. Server access
violations are a known problem in 6.2L+ and are resolved in 6.2N12 or
higher. (This is a patch to 6.2N03 for OpenVMS and a patch to 6.2N05
on Alpha OpenVMS).
REASON FOR ACC/VIO:
Access violations on the server process are a by-product of a
"watch-dog" function that did not properly lock shared memory
during reads.
Also, all access violations associated with remote client
connections have been fixed.
Other things to look for:
- Make sure they have virtual terminals ENABLED. This is a
requirement for all connection types and protocols. Terminals
should show as VTAx:
The following describes how to implement virtual
terminals on VMS. It is a requirement for PROGRESS 6.2L
and above, and advisable for PROGRESS 6.2G.
$ set def sys$system
$ run sysgen
SYSGEN> show/hex tty_defchar2
Param Name Current Default Minimum Maximum Unit Dynamic
------------ -------- -------- -------- ------- ------------
TTY_DEFCHAR2 00001002 00001002 00000000 FFFFFFFF Bit-Encoded
SYSGEN>
Take the current value, in this case 1002, add 20000 (hex)
to this value which gives you 21002.
Convert this value to decimal.
(The easiest way to do this is exit to the $
and type the following:
$ a=%x21002
$ sho sym a
A = 135170 Hex = 00021002 Octal = 00000410002
The decimal value is 135170.)
SYSGEN> use current
SYSGEN> set tty_defchar2 135170
SYSGEN> write current (to update the system parameter file
- vaxvmssys.par
which gets read on system reboot)
SYSGEN> connect vta0:
oadapter/driver=ttdriver (FOR VMS < 6.2)
(tell the system to go and load the driver)
For Alpha OpenVMS 6.2+
$ sysmanio = "$sysman io"
$ sysmanio
_IO function: connect vta0:
oadapter/driver=
sys$loadable_images:sys$ttdriver.exe
$
To get this new value to take effect, you will have to reboot the
machine.
You will also have to add the following lines into
sys$startup:systartup_v5.com
(or systartup_vms.com on V6 of VMS)
to make sure that the driver is loaded on every reboot:
$ run sys$system:sysgen
connect vta0:
oadapter/driver=ttdriver
exit
$
For OpenVMS 6.2 and higher you will need to add the following into
systartup_vms.com:
$ SYSMANIO = "SYSMAN IO"
$ SYSMANIO CONNECT VTA0:/NOADAPTER/DRIVER=
SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE
$
If after reboot you want to check that virtual terminals
have actually been implemented, you can use the
$ show terminal
command. The terminal should have changed from LTAn: to VTAn:
To enable virtual terminals when connecting in over
TCP using DEC TCP/IP Services for VMS (UCX) do the following:
UCX> set communication/remote_terminal=virtual_terminal
You will have to stop and restart UCX to implement the virtual
terminals.
These are the only terminal type that Progress will support on VMS.
If a user ctrl-y's or disconnects abnormally, Progress will clean up
properly if virtual terminals are enabled. If they are not enabled
this can results in access violations and memory violations.
Progress Software Technical Support Note # 12783