TCPIP Services V5.4 TELNETSYM inconsistent behavior

[Richard Jordan]

We have a forms package for the MANMAN product that prints form backgrounds and terms as overlays; they are setup and page setup modules in the printer queue device control libraries. They were developed on LaserJet 3 and 4 printers using LAT DECservers and serial connections, and worked quite well.

Lately we've been required to work with Jetdirect network print servers and much newer Laserjets, and life has become interesting. All the forms had leading DCS and trailing ST characters and just worked with LAT. When we switched to TELNET printing all manner of problems occurred, mostly inconsistent.

Some forms required removing the DCS/ST so they would not print spurious characters, but continued to work as overlays without them (which should not have happened; the VMS print driver should have inserted a hard formfeed between the set module and the file being printed. And on some systems it still does.

Some systems stopped working with 8-bit DCS/ST but required the 7-bit versions to still work as overlays. We have never made any customizations to TELNET or the symbiont (if its even possible) to require 8 versus 7 bit character support so I have no idea why one would stop working and the other start. Only the DCS/ST characters had to change (there were no 8th bit set characters in the form modules, though).

One site, running VMS 7.3 and TCPIP V5.1 at the time, needed every form to have additional literal pairs inserted at the end of every line in the terms and conditions to get back double spacing that had 'just worked' before. This was with an LJ5000 series printer, replacing an older serial connected 4si.

Another site had an LJ8000 Laserjet replaced by the same model, newer firmware, and had to have its forms switched from 8 to 7 bit DCS/ST. An actual printer model change almost always required tweaking and customizing. This NEVER happened prior to moving to TCPIP transport os the much newer HP laserjets.

Right now I'm fighting another problem. Two DS10s running OpenVMS V7.3-2, current ECOs, TCPIP V5.4 ECO 5.

The local uses TCPIP$TELNETSYM to talk to an LJ4000 via a jetdirect slot card. The remote talks to a LJ9000 with embedded jetdirect. Two identical queueus were set up, the same device control library and form definitions used on both sides, and the same simple text file to print.

The remote system will print a form as an overlay WITHOUT the DCS/ST pair, and prints spurious characters at the beginning of the page, but still overlays if DCS/ST are present in the module.

The local system will NOT print the form as an overlay unless DCS/ST is present; the text prints on a following page. It does print spurious characters if DCS/ST is present.

We ran both queues with debug mode 4 (dumping output buffers to the log). The remote printer does NOT get sent a formfeed between the setup module and the actual file, regardless of the presence of the DCS/ST pair in the setup module, while the local printer DOES get a formfeed if the DCS/ST is not present.

The log is showing what TELNETSYM sends to the printers via the network. That formfeed is not the result of the different printer/jetdirect in use; its coming from the VMS side.

We rebuilt the queues and libraries from scratch, made sure none of the TCPIP$TELNETSYM logicals were set (except for debug), restarted the whole TELNETSYM subsystem on both nodes. No change in behavior.

Is there any way to determine why we're getting such inconsistent behavior given two identical setups? Is there any way, perhaps even with newer TCPIP versions to get better control of the print symbionts to prevent these problems?

Thanks...

[John Gillings]

Richard,

TELNETSYM is notoriously fickle. Have you considered using DCPS instead? It's free with your OpenVMS license.

[Hakan Zanderau ( Anders]

Are there any logical names defined ?

$ SHOW LOGICAL *TELNETSYM*

regards,

Hakan Zanderau
HA-solutions

[Phil.Howell]

Have you tried setting this up using relay queues, although this brings lpd into the mix, it may give you more consistent results.
Phil

[Richard Jordan]

John
it may be worth a look. It was not 'free' when the forms were developed and was too expensive for our prospective customers. It depends on how much work would be involved in converting to that product.

Hakan,
initially none of the TELNETSYM modifying logicals were defined on either system (there are some logicals present simply because the product is enabled and running). During testing we enabled the debug and raw mode logicals; the behavior changed as expected with 'raw' but the inconsistency regarding the insertion of a formfeed between the module and the text being printed did not change as a result of trying the various logicals.

Phil,
we use LPD queues to load bitmap fonts and macros into the laserjets; LAT could load those but we could never get TELNETSYM to do so reliably. However the actual forms never seemed to work over LPD; I never had time to debug it to find out why (and right now I don't recall the specific failure modes). TELNETSYM queues could be made to work where none of the form modifications mentioned in the original post had any effect on the LPD queue non-workability. Given the current problems we may have to go back and try that again though.

I keep telling them we need LAT back; they keep saying 'no'...

Thanks for the responses.

[Richard Jordan]

Closed