5.1BPK6 LAT PRINTER PROBLEM: " waiting for lpXX to become ready (offline ?)"

[Panos Agoros]

Dear all,

during the process of migration from a production 5.1A system to a 5.1BPK6, I have installed/configured LAT and imported the original configuration. For some reason I cannot comprehend, printing queues do not work. Everything is double checked and supposed to be working since I have repeated the same process on the same server, but going to 5.1A instead of 5.1B, and it worked straight away.

The error message returned by "lpc status" & "lpq -PlpXX" is "waiting for lpXX to become ready (offline ?)".

The same print queue configured in exactly the same way on the original 5.1A system works and is printing happily. The inittab, printcap, latstartup.conf entries have been imported from the original system.

I have been through the troubleshooting steps proposed in the NETWORK CONNECTIONS manual (10.10 Solving LAT Problems) as per this specific error message but without result.

any clue?

thank you!

Panos

[Panos Agoros]

To be more precise, actually the problem is that I cannot communicate with the terminal server where the printer is connected (#latcp -d -H ===> "Remote node does not exist"). Does lat store the known servers in a specific file? how does it work?

thanks

[Rob Leadbeater]

Hi Panos,

Is the terminal server actually live on the network ?

Where does it download its code from ?

You might get a hint from /etc/bootptab

Cheers,

Rob

[Panos Agoros]

Hi Rob,


there is no concern about the terminal server is working, since we can print to a similar queue (same term.server, same port) from the original system.

upon issue of the latcp -d -H command on the original system we get a response, while this is not the case from our new 5.1B system.

[Rob Leadbeater]

Hi,

How are you specifying in these examples ? By hostname ?

Seeing the exact commands used, and the exact output will probably help.

Seeing the relevant sections of /etc/printcap for the printer involved would probably be useful as well.

Cheers,

Rob

[Rob Leadbeater]

Another thought.... I take it that LAT is enabled in the kernel for the new machine ?

Cheers,

Rob

[Steven Schweda]

I do almost nothing with LAT on Tru64, but
...

These systems are on the same physical
network segment, right? (LAT doesn't get
through an IP router.)

What do these say (on each system)?:

latcp -d
latcp -d -l

> I have been through the troubleshooting
> steps [...]

That's nice, but we can't see what you did or
what you saw when you did these things.

What, exactly, is in the printcap file for
this printer?

What is the network interface on the new
system? "man lat_intro" says things like:

LAT is not supported over NetRAIN
virtual interfaces [...]

What is the terminal server? Does it do only
LAT, or Telnet, too?

[Panos Agoros]

Hello,


thanks everybody for your response, the issue is solved by now!

The LAT configuration was correct. What was going wrong was that the new system was in a different VLAN than the original one. Eventhough the printer's subnet technically communicates with both VLAN's (the original box's and the new one's), LAT info couldnt get through. We entered at the new system an IP @ on another VLAN and it worked like a charm.

Conclusion: LAT doesnt like VLAN's...

thanks so much once again for your time

Panos

[Steven Schweda]

> Conclusion: LAT doesnt like VLAN's...

The "L" in "LAT" is for "Local", and the
people who named it were very serious about
that.. It's not a routable protocol, so, as
I said, "LAT doesn't get through an IP
router."

LAT can be _bridged_, however, so long as the
bridging is not too slow. (Long latencies
will cause trouble.) I have dim memories of
9600b/s modems on a bridging+routing leased
line between California and Minnesota, and,
while we didn't actually _rely_ on LAT over
that link, we never had any actual trouble
with it, either. (We could also tell when
there was a power problem at the other end,
because when their power came back on, their
DECservers would do MOP downloads from our
VAXes, because ours would still be up, while
theirs would still be trying to re-boot. The
printing console terminals on the VAXes all
got very busy on those occasions.)