TELNET Symbiont Changed Between VMS Versions?

[Robert Atkinson]

We're running a production system on VMS 7.2-2 and testing our upgrade to VMS 7.3-2.

One thing we've found is that we are getting blank pages at the start of some printouts, when we send setup modules. In this case, an escape sequence to put the printer into landscape.

This seems to be caused by the TELNET symbiont on 7.3-2 sending CRLF, whereas VMS 7.2-2 only sends CR.

I've attached the trace dumps for both.

Has anyone else seen this problem.

Robert.

[Robert Atkinson]

And the other trace file....

[Anton van Ruitenbeek]

Robert,

Telnet isn't from VMS but TCPIP. Which version of TCPIP youre using ?

Do you have also set up the needed TCPIP$TELNETSYM_ logicals ?
These logicals must be active before starting the queue. So if logicals are changed, the queue need to be stopped and started. These logicals are only used when the queue is started. So sort of dynamic for new queues.

I think the following logicals wil help you:
TCPIP$TELNETSYM_RAW_TCP = "TRUE"
TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS = "35"

Minimize and structure youre messages and environment:
TCPIP$TELNETSYM_LOG_KEEP = "3"
TCPIP$TELNETSYM_NO_OPCOM = "TRUE"
TCPIP$TELNETSYM_SCRATCH = ":[TELNETSYM]

AvR

[Wim Van den Wyngaert]

http://h71000.www7.hp.com/DOC/732final/6526/6526pro_051.html

You may have lost a logical (2nd bullet).

If not what are/were your tcp versions ?

Wim

[Robert Atkinson]

The producation system is running 5.1 Eco3 and the upgrade node is running 5.4, so definitely a change there.

I've checked the logicals, and everything seems to be the same.

Any other ideas?

Rob.

[Willem Grooters]

Robert,

Having compared the dumpfiles, I don't see the difference in CR/LF and CR. In boths dumps, records seem bo be ending with the combination (hex) 0D0A.

Assuming that the dump are from the same (or a very similar) file - the second has one 80-character line moreat the end - most significant is a difference in initialisation. I don't know whether this is a symbiont thing, but I hardly think that would make a real difference.

I would take a good look at the form definitions.

Willem

[Robert Atkinson]

Willem,
if you look at the 'initialisation' (where the setup module is sent) for the text "&l2E", this is where the LF is sent as an extra piece of data.

I believe this is causing the blank page, but why are 5.1 and 5.4 doing different things?

Rob.

[Wim Van den Wyngaert]

Robert,

http://h71000.www7.hp.com/doc/73final/6526/6526pro_042.html#telnetsym_formfeed_suppression

Your logicals holds a different value or the behaviour changed. As I understand it, it should contain 35 or you will get the formfeeds.

Wim

[Robert Atkinson]

Willem, both systems are set the same :-

Beta:
(LNM$SYSTEM_TABLE)

"TCPIP$TELNETSYM_IDLE_TIMEOUT" = "0 00:00:10.00"
"TCPIP$TELNETSYM_RETRY_INTERVAL" = "0 00:00:30.00"
"TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS" = "34"
"TCPIP$TELNET_NO_REM_ID" = "TRUE"

Delta:
(LNM$SYSTEM_TABLE)

"TCPIP$TELNETSYM_ENABLE" = ".1.."
"TCPIP$TELNETSYM_IDLE_TIMEOUT" = "0 00:00:10.00"
"TCPIP$TELNETSYM_RETRY_INTERVAL" = "0 00:00:30.00"
"TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS" = "34"
"TCPIP$TELNET_ENABLE" = ".1.."
"TCPIP$TELNET_NO_REM_ID" = "TRUE"

[Jan van den Ende]

Robert,

your TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS specifies "34", so I would _EXPECT_ you to get the foemfeeds, but, on _BOTH_ systems.
So I think you WILL get rid of your undesired formfeeds by adjusting the value (remember to re-start your queues!),

but, the question remains; "Why the difference between the versions?????"

Jan

[Robert Atkinson]

Jan,
you're barking up the wrong tree, mate.

There are no formfeeds in the datastream, other than those in the file itself.

The problem occurs when setup modules are sent. If I send the data without the modules, there is no blank page.

As I've said, I'm fairly convinced that it is the LF being sent after the setup module that is actually causing the balnk page, because this is seen by the printer as printable data. In v5.1 this LF is not sent.

Rob.

[Anton van Ruitenbeek]

Robert,

I've posted this before, but I don't see it, so now again (something wrong at W$dozes ?)

I know with previous versions that the logical "UCX/TCPIP$TELNETSYM_ENABLE" was needed. Now I cannot find the value/need for it.
With IP 5.x I don't use this anymore and I don't get this problem. At the web I can even not find the logical again.
Maybe you should consider to remove this, stop/start the queue again (dont forget the /reset).

Manual: 23:
'TELNETSYM adds escape (0xFF) bytes in the data stream so they are not mistakenly interpreted as TELNET protocol IAD commands.'
'TELNETSYM can remove (suppress) any form feeds (0x0c) characters that the OpenVMS print symbiont adds to the beginning or end of print jobs. Use TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS logical name to control this function, as described in Section 23.6.4.1'
And reading this section I think you set a value of 35 or 17.

Yes, still I don't understand the differend interpretation. It is cheap to say, but don't forget it's IP. Some bugs are features.

AvR

[Willem Grooters]

Robert,

NOT the same. Delta holds:

"TCPIP$TELNETSYM_ENABLE" = ".1.."

might be a result of different cut-'n-paste, but if not:
What the dots stand for - presumibly non-printable characters. I don't know what this logical does (didn't look it up) but if this system that prints that extra linefeed or causing a formfeed to start (blank page?) you may have found the reason.

Willem

[Wim Van den Wyngaert]

Willem,

The logicals are defined by the startup procedure (tcpip generate servi).
But normally they are removed after startup (on my version 5.3 eco3).

Maybe startup went wrong ?

Wim

[Robert Atkinson]

OK, restarted IP services, which has got rid of the _enable logical.

Retested printing, but still producing a blank page.

I really honestly and truly think someone has changed the symbiont, possibly without realising the impact.

Rob.

[Wim Van den Wyngaert]

Robert,

You're probably right. But if I was you, I would try the 35 and see if it works. Maybe the old 34 worked incorrectly and worked as 35.

HP should make a web interface where you can select an exe and see al the modifications that are done (within a VMS version). Even the smallest one.

Wim

[Willem Grooters]

Wim,

For patches this already exists - What exe's have been changed is in patch release notes. The idea to have an interface where the history of chnages in _executables_ could be traced has my approval!

Willem

[Jan van den Ende]

Wim, Willem,

if this idea becomes a request and needs supporters: count me in.

jpe

[Martin Hebron]

I think it will work if you retry it.
Martin H

[Jeremy Stubbs]

There was a change in the past along these lines:

By default TCPIP will add a at the end of each print job , but in cases were a setup module is used at the start of a print job (i.e. to reset the printer ) if the setup module contains non ANSI standard escape sequences TCPIP will insert a additional formfeed between the setup module and the print job.

Really a SETUP module with none ANSI standard escape sequences should be wrapped in EscPEsc\

However a third bit setting was added to the suppress formfeed setting. Thus to retain your previous setting of 34, but also suppress the adding of the FF to the SETUP module you should now set it to 42

34 had bits 5 and 1 set. Setting bit 3 increases this to 42 (i.e add 8)

Hope this helps,

Jed

[Wim Van den Wyngaert]

Robert,

is your problem now solved ?

Jed,

Where is this 3rd bit documented ? Where are the release notes ? Starting from which tcp version ?

Wim

[Robert Atkinson]

We were working on it with our support company, when it suddenly rectified itself. As yet, I don't know why!

I'm waiting for it to come back, so I can pick the problem up again.

Rob.

[Jeremy Stubbs]

Wim,

The 3rd bit received very brief documentation in the UCX 4.2 ECO 3 release notes. One day it might make the Management Guide ? ;0)

Have to say, I thought it wasn't introduced until TCPIP (rather than UCX), but looks like I'm wrong (not the first time)

Jed

[Jeff Muehlbauer_1]

Robert,

I've had the same problem for years (this is going way back to VMS 5.5 and UCX) and have just written it off as not being repair-able. Were you able to solve the problem with the TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS set to 42? It doesn't work for me.

Right now, I'm doing a lot more with the HP printer. I'm not just sending escape sequences to turn on/off features of the printer, I'm also sending macros (like pre-printed forms) which get overlaid on the printout as if being printed on a pre-printed form.

The issue of the form feed before the printout is a real pain; I'm interested in finding out if you were able to get it fixed.

Thanks

[Robert Atkinson]

I've not seen this problem again, so rather bemused by where it came from.

For reference, we're still using these logicals :-

ALPHA_ROB$ sh log *telnet*

"OPENVMS$TELNET" = "SYS$SYSTEM:TCPIP$TELNET.EXE"
"TCPIP$TELNETSYM_IDLE_TIMEOUT" = "0 00:00:10.00"
"TCPIP$TELNETSYM_RETRY_INTERVAL" = "0 00:00:30.00"
"TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS" = "34"
"TCPIP$TELNET_NO_REM_ID" = "TRUE"

Rob.