Set term/nohangup on IA64 OpenVMS

[Bill Hallman]

I am converting an application from OpenVMS VAX V7.1 to Integrity V8.3. A procedure that creates a separate debugging session requires that I set the terminal to \nohangup, but the command '$ set term/nohangup/perm' entered on the IA64 system will not work, and causes the term dev type to be set to 'unknown' It works on the VAX with the same emulator and procedure. I am running with full privs turned on, from Reflection using telnet. Any ideas?

[Steven Schweda]

> [...] using telnet.

I don't even know what SET TERMINAL /NOHANGUP
is supposed to mean for a Telnet connection.
I also don't know anything about your IP
software (which must differ, at least in its
version, between these two systems).

If you're in the mood to educate me, what,
exactly, "requires that [you] set the
terminal to \nohangup"?

Around here:

alp $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

and, even when I have the privilege to do it,
SET TERM /NOHANG /PERM seems to have no
obvious effect on the TNAxx device.

alp $ set ter /nohang /perm /log
%SET-I-TERMSET, terminal TNA67: set to NOHANGUP
alp $ pipe show term | sear sys$input hang
No Modem No Local_echo No Autobaud Hangup

[Bill Hallman]

Okay, answers in order you asked:
My purpose, as I tried to briefly state,
is to create a separate OpenVMS Symbolic
Debugger session, as described in the Debugger Manual section
14.2, "Debugging Screen-Oriented Programs"
The relevant extract is this:
3. Enter these commands (you need LOG_IO or PHY_IO privilege):
$ SET PROCESS/PRIV=LOG_IO
$ SET TERMINAL/NOHANG/PERMANENT
$ LOGOUT/NOHANG

***** The VAX is running Multinet as shown:
AK6:Main#1> !this is the VAX system
AK6:Main#1> multinet show/version
Process Software MultiNet V4.4 Rev A-X, VAX 4000-106A, OpenVMS VAX V7.1
AK6:Main#1> sho term
Terminal: _NTY32: Device_Type: VT300_Series Owner: Main#1
No Modem No Local_echo Autobaud Hangup
AK6:Main#1> set term/nohang/perm
AK6:Main#1> sho term
Terminal: _NTY32: Device_Type: Unknown
Owner: Main#1
No Modem No Local_echo Autobaud No Hangup

****** The IA64 is using TCP/IP Services:
SPJP93:Main#1> !This is the IA64 system
SPJP93:Main#1> tcpip sho version
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6
on an HP rx2620 (1.60GHz/3.0MB) running OpenVMS V8.3
SPJP93:Main#1> sho term
Terminal: _TNA183: Device_Type: VT300_Series Owner: Main#1
No Modem No Local_echo No Autobaud Hangup

SPJP93:Main#1> tcpip sho version
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6
on an HP rx2620 (1.60GHz/3.0MB) running OpenVMS V8.3
SPJP93:Main#1> sho term
Terminal: _TNA183: Device_Type: VT300_Series Owner: Main#1
No Modem No Local_echo No Autobaud Hangup

SPJP93:Main#1> set term/nohang/perm
SPJP93:Main#1> sho term
Terminal: _TNA183: Device_Type: Unknown Owner: Main#1
No Modem No Local_echo No Autobaud Hangup


So, if the problem is TCP/IP Services vs. Multinet, does anybody know how I can set up a separate debugging session my IA64 system?

[Robert Gezelter]

Bill,

From which version of the Debugger Manual is that citation? There have been many changes to the debugger in the interval between 7.1 and 8.3.

Also, please check the value of logical name DBG$PROCESS (and report it here).

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> [...] does anybody know how I can set up a
> separate debugging session my IA64 system?

Here, as is often the case, it might have
saved some time and bewilderment if you had
emphasized the description of the actual
problem to be solved, rather than the request
for help in implementing some particular
(hopelessly doomed?) technique intended to
solve that problem. (Or perhaps I need to
read more carefully.)

I don't use the debugger enough to be very
useful here, but I wouldn't expect much from
applying stuff to a Telnet TN device which
was originally intended for a real TT or TX
serial port. (Even if it worked on
someone's NTY device.)

If you have a working X (DECwindows)
environment (so that CREATE /TERMINAL does
good things), then you might get some useful
behavior from the technique outlined in
section 9.8.3.3, "Displaying the Command
Interface and Program Input/Output in
Separate DECterm Windows":

http://h71000.www7.hp.com/doc/82final/4538/4538pro_019.html#d_userinterf_nondwseparate_sec

(That is the Debugger manual to which you
referred, right?)

It seemed to do some reasonable stuff on my
XP1000 workstation.

[John Gillings · Accepted solution]

Bill,

There are many ways to skin this particular cat. All you really need to do is point DBG$INPUT and DBG$OUTPUT at a known terminal and run your program under DEBUG. The purpose of /NOHANGUP in this case is to (try to) prevent the system from deallocating the terminal after the process logs out, but there are other possibilities to achieve the same effect.

Make sure the process that will run DEBUG has SHARE privilege. Login a session and determine the terminal name, let's assume it's TNA41: Now type:

$ WAIT 10

this will cause the current process to wait for 10 hours. From the DEBUG sessions type:

$ DEFINE DBG$INPUT TNA41:
$ DEFINE DBG$OUTPUT TNA41:
$ RUN/DEBUG yourprogram

The DEBUG prompt should appear on the WAITing terminal.

Once you've finished debugging, you can cancel the WAIT command with ^Y. Or if you see a $ prompt (meaning the other process has woken from the wait), just enter another WAIT command.

This mechanism will work for any type of terminal or connection (I used to use it with real VT220s connected via LAT).

If you have Reflection, another option is to start an X server on your PC and use the DEBUG X interface. From the process to run DEBUG type:

$ SET DISPLAY/CREATE/NODE=yourPC/TRANSPORT=TCPIP
$ RUN/DEBUG yourprogram

The DEBUG X windows should appear on your PC.

[Bill Hallman]

Sorry I haven't responsed earlier. Lots of ideas here but I haven't gotten any to work yet. I don't have DECW, probably won't till well after this app must be in place.

The Debugger manual citation is from V7.2, for VMS IA64 V8.2, Nov. 2005.

John, I tried your 'WAIT 10' method, but still get 'terminal is already allocated' errors. I will try other variations, but for now I am using workarounds, as I am on a very tight schedule for this app. I appreciate all the comments, and will continue to look for other ideas that others may wish to tender.

[Jess Goodman]

Bill,

John's suggestion to "WAIT 10" is to be used INSTEAD of what you were doing.
* Login.
* SHOW TERM
* WAIT 10
* Do NOT attempt to allocate the terminal from another process. Do NOT attempt to logout.

Then from other process you just define dbg$input and dbg$output and run the debugger. You have 10 hours to find the bug (tick, tick, tick).

Another method that should work is to do what you were doing before but use the command "OPEN/READ/SHARE JUNK TNAnnn:" instead of "ALLOCATE TNAnnn:".

[Bill Hallman]

I thought that is what I tried, but this time it worked. Many thanks, everybody!

[Jess Goodman]

Sorry, I should have said that you can do OPEN/READ/SHARE JUNK TNAnnn: from the other process, and THEN logout.

(What you were doing if I understand you correctly is LOGOUT/NOHANG, and then ALLOCATE TNAnnn: from the other process.)