Title: | DEBUG |
Notice: | Updated locations for reporting QARs -- see note 834.1 |
Moderator: | LOWFAT::DIETER |
Created: | Fri Jan 24 1986 |
Last Modified: | Wed Jun 04 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1868 |
Total number of notes: | 8200 |
OpenVMS V7.1, Debugger V7.1-000, Alpha A customer is reporting that he is unable to run the debugger when he telnets or set hosts into his system. When he attempts to run an image linked with /debug, the attempt fails with the following errors. ============================================================================== $ run sumps XIO: unable to open connection _WSA1: after 0 requests (0 known processed) with 0 events remaining. %DEBUG-F-UNAOPNDIS, Unable to open display _WSA1: ============================================================================= Even after defining dbg$decw$display to be " ", he still gets this error and is not able to run the debugger at all. I have attached his set host log file below, which shows the steps he has taken to run in debug mode, his *dbg* logicals, and his terminal settings. I have also asked him to provide the results of $show log *decw* and $show display. I have tried to reproduce this, but have so far been unsuccessful. When I issue a $define decw$display wsa1:, I can get the %debug-f-unaopndis error, but not the XIO error. And, if I then define dbg$decw$display to be " ", I am able to use the character cell version of the debugger. Anyone have any ideas or suggestions as to what is going on here, or how to further troubleshoot this? I've done everything I can think of and need some help. Thanks, Jerry ======================================================================== $ show term Terminal: _RTA1: Device_Type: VT300_Series Owner: CONWAY Remote Port Info: CALVIN::CONWAY Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 35 Terminal Characteristics: Interactive Echo Type_ahead No Escape Hostsync TTsync Lowercase Tab Wrap Scope No Remote Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo No Autobaud Hangup No Brdcstmbx No DMA Altypeahd Set_speed No Commsync Line Editing Insert editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics Soft Characters Printer port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video Edit_mode DEC_CRT DEC_CRT2 DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color VMS Style Input ============================================================================== $ show logical *dbg* (LNM$PROCESS_TABLE) (LNM$JOB_8115D580) (LNM$GROUP_000311) (LNM$SYSTEM_TABLE) "DBG$HA_DEFAULTS" = "SYS$LOGIN:DBG$HA_DEFAULTS.DAT" = "SYS$LIBRARY:DBG$HA_DEFAULTS.DAT" "DBG$INPUT" = "SYS$INPUT:" "DBG$OUTPUT" = "SYS$OUTPUT:" (DECW$LOGICAL_NAMES) ============================================================================== $ show device ws Device Device Error Name Status Count WSA0: Offline 0 WSA1: Online 0 WSA2: Online 0 ============================================================================== $ run sumps XIO: unable to open connection _WSA1: after 0 requests (0 known processed) with 0 events remaining. %DEBUG-F-UNAOPNDIS, Unable to open display _WSA1: Interrupt $ Interrupt Are you repeating ^Y to abort the remote session on node IPWK2? Y %REM-S-END, control returned to node CALVIN:: ============================================================================== $ define dbg$decw$display " " $ r sumps XIO: unable to open connection _WSA1: after 0 requests (0 known processed) with 0 events remaining. %DEBUG-F-UNAOPNDIS, Unable to open display _WSA1:
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1861.1 | decw$display defined in system table | CSC32::J_HENSON | Don't get even, get ahead! | Tue May 06 1997 12:11 | 33 |
I have an update on this. I don't quite understand how this customer's situation came to be, but thought that I should post what I know. It might help someone else later, and it looks to me like an issue that needs to be explored by engineering. The results of $show log *decw* showed, among other things, the following. "DECW$DISPLAY" = "_WSA1:" in the SYSTEM table. Also, $show display revealed Device: WSA1: [exec] Node: 0 Transport: LOCAL Server: 0 Screen: 0 The customer defined decw$display to be " " in the process table, and is now able to use the debugger. What I don't understand is how decw$display came to be defined in the system table, but that's another issue and one for the system manager. What I also don't understand (and haven't been able to test for obvious reasons) is why decw$display being defined in the system table would override dbg$decw$display being defined in the process table. Perhaps someone can test this on a system that has few users. The only 7.1 system I have access to has a lot of users, and I'm afraid that defining decw$display as a system logical could cause some real heartburn. Anyway, the customer is able to use the debugger, and not likely to want to pursue this any further. Jerry |