$ set term/readsync
$
**** Fatal BUG CHECK, version = V7.3 INVEXCEPTN, Exception while
above ASTDEL or on interrupt stack
Crash CPU: 00 Primary CPU: 00
Active/available CPU masks: 00000001/00000001
Current process = NULL
Register dump
R0 = 00000008
R1 = 04080000
R2 = 0000000A
R3 = 81BE6E90
R4 = 81E5C400
R5 = 81BE6E30
R6 = 823F6210
R7 = 00000034
R8 = 00003DA8
R9 = 00279374
R10= 00000000
R11= 00000000
AP = 000EEDD0
FP = 000EEDAC
SP = 823F7584
PC = 819AF87F
PSL= 04080009
Kernel/interrupt/boot stack
823F758C 00000004
823F7590 000EEDAC
823F7594 FFFFFFFD
823F7598 81E3AE00
823F759C 0001FF0D
823F75A0 00000001
823F75A4 00000005
823F75A8 0000000C
823F75AC 00000005
823F75B0 FE1E6E60
823F75B4 81BE4CA1
823F75B8 04080004
823F75BC 00000026
823F75C0 00000000
823F75C4 0000000A
823F75C8 00000013
823F75CC 81A31B48
823F75D0 81A31B48
823F75D4 00000000
823F75D8 00000000
823F75DC 81A2AD43
823F75E0 04C30008
823F75E4 00000000
823F75E8 0000000A
823F75EC 823F6000
823F75F0 81E78B40
823F75F4 82637A00
823F75F8 00002240
823F75FC 81A2AFA1
Loaded images
<SYS$LDR>NET$MESSAGE.EXE 8184E400 81855000
[SYSMSG]SYSMSG.EXE 81855200 8189BC00
[SYS$LDR]SYSLDR_DYN.EXE 81BEB800 81BED800
[SYS$LDR]DDIF$RMS_EXTENSION.EXE 81BEDC00 81BEEE00
[SYS$LDR]RECOVERY_UNIT_SERVICES.EXE 81BEF000 81BEF800
[SYS$LDR]RMS.EXE 8189BE00 818C8800
SYS$NTA.EXE 81937E00 81938000
VAXCLUSTER_CACHE.EXE 81919200 8191DE00
SYS$NETWORK_SERVICES.EXE 8191E400 81935C00
SYS$UTC_SERVICES.EXE 81938400 81939200
SYS$TRANSACTION_SERVICES.EXE 81939800 81947600
SYS$IPC_SERVICES.EXE 81947A00 81965A00
CPULOA.EXE 81965C00 8196B000
LMF$GROUP_TABLE.EXE 8196D400 8196EE00
SYSLICENSE.EXE 8196F200 81972400
F11BXQP.EXE 81972800 81992000
SNAPSHOT_SERVICES.EXE 81992800 81993400
SYSGETSYI.EXE 81993A00 81995A00
SYSDEVICE.EXE 81995E00 81998800
MESSAGE_ROUTINES.EXE 81998E00 8199F000
EXCEPTION.EXE 819AF600 819B9E00
LOGICAL_NAMES.EXE 819BA600 819DDE00
SECURITY.EXE 819DE800 819E8200
LOCKING.EXE 819E8A00 819EF800
PAGE_MANAGEMENT.EXE 819F0200 819FA200
WORKING_SET_MANAGEMENT.EXE 81A0B000 81A10E00
IMAGE_MANAGEMENT.EXE 81A11800 81A14E00
EVENT_FLAGS_AND_ASTS.EXE 81A15400 81A17600
IO_ROUTINES.EXE 81A18000 81A28600
PROCESS_MANAGEMENT.EXE 81A2A000 81A37A00
ERRORLOG.EXE 81BDD000 81BDDC00
PRIMITIVE_IO.EXE 81BDE200 81BDF400
SYSTEM_SYNCHRONIZATION_UNI.EXE 81BDF800 81BE3C00
SYSTEM_PRIMITIVES_MIN.EXE 81BE4200 81BE8000
**** Starting memory dump, writing dump to unit number 0
First of all, I don't have a VAXstation 4000-90, mine are VS
4000-90A's but these systems are pretty much alike.
There are two serial ports. As seen on on the back of the system, the
left one has a DEC423 (or MMJ) connector and the one on the right uses
a male
DB25 connector. They both have a terminal logo and a printer icon,
though the order of the icons is reversed above the DB25 connector.
Here the printer icon comes first which makes me assume that this is
the port you've been using, right?
One *-90A has a working graphics board (Argon), the other (called
Chloor) has the S3 switch in the serial console mode. The terminal
device names are as follows:
DEC324 RS232 VMS version
Argon TTA3 TTA2 7.3
Chloor OPA0 TTA2 7.2
So I did a $ set term/readsync while logged in on port TTA2 of
Chloor.
When the $ prompt returned, I hit RETURN a few times. The cursor just
returned to the the first position of the line without a linefeed.
A SHOW TERM did not do anything after hitting RETURN obviously
because the system never received the command. The terminal hung
but the system did not crash.
Next, the procedure was repeated on OPA0 of Chloor and the system
stopped responding after issuing that command.
The system did reboot, so I hookup a dumb terminal to OPA0 and
repeated the procedure. And got a dump quite similar to yours but
unfortunately could not record it since it was on a Citoh terminal.
The problem is not limited to your system or your hardware model nor
VMS V7.3. You could try a work around on port TTA2.
The question remains why this happens and I think it is because OPA0
is also the console output device. Switching on READSYNC probably
affects a system process that needs OPA0 without this modification and
kills VMS with it.
Hans
You might want to look into Kermit:
http://www.columbia.edu/kermit/kermit.html -- ISTR using it over serial
lines and dial-up to transfer files to VAXen.
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Which is what I do too. I get the Montagar VMS licenses on a Windows
XP system.
I copy the license contents (control-C), do a $ CREATE NEW.LMF and
paste the contents.
The difference may be that I use a telnet session. There are only two
alpha's close enough to the pc to use a serial console.
Anyway, READSYNC doesn't solve that. You might want to increase the
terminal speed. On OPA0 that may not a good idea
but on TTA2 you can run 19200 and 38400 bps. You'd need a H8575-A
(DB25 to mmj) connector though.
Hans
If you just want to get rid off the buffer overruns, I suggest you use the
$ SET TERMINAL /HOSTSYNC
I did try that. I tried SET TERMINAL /HOSTSYNC and SET TERMINAL /
HOSTSYNC /TTSYNC. I still get data overrun when I paste into PuTTY.
You can see from the output sample below that I'm trying to put a
license on the machine. I have configured PuTTY for XON/XOFF and am
using a MMJ cable from the VAX to the PC with a DB-9 connector on the
PC end...
$ set term/hostsync/ttsync
$
$
$ $!
$ $! COMPAQ HOBBY LICENSE AGREEMENT
$ $! For OpenVMS
$ $!
$ $!
$ $!
$ $! This document is the legal agreement governing your use of
the Software.
$ $! Please store it in a safe place.
$ $!
$ $!
$ $! LICENSE TERMS
$ $!
$ $! 1. GRANT
$ $!
$ $! Upon your qualification for this license and your signature
on this
$ $!
%RMS-F-RER, file read error
-SYSTEM-W-DATAOVERUN, data overrun
$ , Compaq Computer Corporation ("COMPAQ") will grant you the
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first
character
$ $! right to use the VAX OpenVMS on a single computer
("Licensed
...
help/message overun
I also saw a web page talking about this issue as it applies to
Kermit:
http://www.columbia.edu/kermit/ckvins.html
So, I will give this a shot...