Que Startup Error

[Warren Landrum_1]

I have created a Telnet device (format = TNAxx:) on an OpenVMS Alpha 7.3-2 machine and mapped that device to a Telnet Listener Port on a Decserver 900 terminal server. Then created a device que that our paging application (RAMPAGE) uses. All this being done because we need to xfer the RAMPAGE modem off of a LAT decserver because we are getting rid of LAT.

OK, so when I init the que, and it tries to start, I get the following error message:

%SYSTEM-F-JBCERROR, error communicating with job controller".

Here is the init command I used:

INIT/QUE/DEVICE=SERVER/START quename -
/ON=server::TNAxx /decsrip="blah blah blah" -
/own=[1,4]/prot=(s:e,o:d,g:r,w:w) -
/base_prio=4/wsdef=0/wsquo=0/wsextent=0 -
/form=default/default=(flag=one.noburst,form=default) -
/library=rampage/processor=rampagesmb

This init command is identical to the one used to create the que for the LAT device, except iiy used an LTAxxx: device instead of a TNxx: device.

Any ideas or do I need to provide more info?

Thanks,

Warren

Ps - this is the last LAT port I've got to get rid of. Have successfully migrated others, so this would be a gerat XMAS present if one of you guys has the answer (-:

[John Gillings]

Warren,

LAT application ports and Telnet ports are totally different beasts.

To replace a LAT terminal queue, use LPD or TELNETSYM. You can't use the same INIT command. See TCPIP documentation for details.

You may need to talk to RAMPAGE to find out if there's a different symbiont that works with TCPIP

[Wim Van den Wyngaert]

Found this.

Q: Can a paging channel modem be connected to a network terminal server?

A: A paging channel modem can be connected to a LAT terminal server, as described in Appendix C in the RamPage Installation Guide.

A paging channel modem can only be connected to an IP terminal server if your OpenVMS TCP/IP software provides a utility for mapping server ports to OpenVMS virtual device names.

All paging channel communications are performed via QIO's from the RamPage paging channel symbiont (under the direction of the OpenVMS Job Controller) thru the OpenVMS TTDRIVER. As such, paging channels can only be shared by members of the same cluster. Therefore, having a paging channel modem on a terminal server provides the benefit of simplified cabling to remote locations, however, the terminal server is incapable of providing the same scheduled and controlled access offered by the Job Controller.

Experienced OpenVMS professionals may be aware of the ability to share network printers on a terminal server across non-clustered systems, however, this task is accomplished by the OpenVMS LAT printer symbiont. This symbiont is restricted to the LAT protocol, and unlike the RamPage symbiont, does not offer the bi-directional communications that would be necessary for exchanging data with a modem.

Wim

[Robert_Boyd]

To set up virtual terminals for TELNET ports:

from http://h71000.www7.hp.com/faq/vmsfaq_011.html

5.42.7 How to enable telnet virtual terminals?

To enable virtual terminal support for telnet and rlogin devices, add the following logical name definitions into SYLOGICALS.COM:


$ DEFINE/SYSTEM/EXECUTIVE TCPIP$RLOGIN_VTA TRUE
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNET_VTA TRUE

See SYS$STARTUP:SYLOGICALS.TEMPLATE for details on the typical contents of SYLOGICALS.COM.

In SYSTARTUP_VMS.COM, ensure that a command similar to the following is invoked:


$ SYSMAN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE

In MODPARAMS.DAT, add the following line or (if already present) mask the specified hexidecimal value into an existing TTY_DEFCHAR2, and perform a subsequent AUTOGEN with an eventual reboot:


TTY_DEFCHAR2 = %X20000

This value is TT2$M_DISCONNECT.

On older TCP/IP Services---versions prior to V5.0---you will have to perform the following UCX command:


$ UCX
UCX> SET CONF COMM/REMOTE=VIRTUAL


Robert

[Warren Landrum_1]

Guys,

Thanks for your input.

I got hold of the RAMPAGE tech support guy and he was able to help me get the solution.

basically, what happened is that a Telnet session had to be created (which I had already done correctly), but the RAMPAGE software actually handles the que creation. This is what he talked me through doing. So it was totally unrelated to UCX or Telnet type symbionts that we are accustomed to dealing with when creating IP print ques.

Thanks again,

Warren

[Warren Landrum_1]

Solution found as described in my reply