LAT port & IA&4 again!

[Antoniov.]

Hello,
I'm sure there is some serious trouble using LAT port with IA64.
Now I cannot print from HP Integrity Server to a barcode printer connnected by a LAT port.
As for my prevous post, this LAT port use DSR/DTR signals.
If port of Decserver is connected to old AXP works good. When is connected to IA64 losts data.
I don't change anything on Decserver. Statements of LAT$SYSTARTUP are the same in boths systems.
LAT ports using XON/XOF work good!
Could anybody tell me where I can download the latest version of MNENG1.SYS?

TIA
Antoniov

[Hoff]

You'll need to debug the application to either identify the program bug or to isolate the OpenVMS or LAT flaw, as was suggested over in the cross-posting out in comp.os.vms.

Moving applications to faster boxes or across architectures (or both) tends to expose latent flaws within application source code.

And yes, there can also be flaws in OpenVMS itself. But these flaws arise at a rather lower frequency than do flaws (latent or blatant) within application code. There's no evidence here (yet) that this is OpenVMS (or the DECserver) at fault. So while you might be certain it's OpenVMS at fault, I'd ask you to prove that.

Prove it's OpenVMS. Don't claim it. Debug the code.

And if it is OpenVMS, then you can use that code with HP to verify the error and the fix.

Here's a list of common coding flaws:

http://h71000.www7.hp.com/wizard/wiz_1661.html

And (as was suggested in c.o.v.) do confirm that what's coming out the far end of the connection is (or is not) receiving the bar code. Use something other than a printer to gather that detail.

[Colin Butcher]

I recommend you look at the network infrastructure. IA64 machines generally have modern 10/100/1000 NICs and do things like "flow control" as well as "auto negotiate" and "hdx / fdx". Depending on the NIC the ALphas may pr may not do all these things too. DECservers are all 10 hdx and don't have things like flow control. Also LAT as a protocol is latency sensitive and doesn't necessarily have all the retransmit stuff in the way that IP does.

Also look at error counters in the DECserver and think about whether you need to modify anyt of the LAT timers.

So, use something like wireshark to capture ethernet packets and see what's really going on down on the wire.

Me, I'd probably assign LAT to a specific NIC on the IA64 box and set the speed / duplex / flow control etc. to say 10 hdx with everything else disabled, then build up from there. Also try a direct wired cross-over cable between the IA64 box and the DECserver to eliminate the network infrastructure.

If all that checks out OK then start to look at LAT in the IA64 box and perhaps consider changing over to "telnetsym in raw mode" using IP instead of using LAT for access to the serial printer.

Good luck.

Cheers, Colin (http://www.xdelta.co.uk).

[Hoff]

MNENG1.SYS was one of the MOP load files for the DECserver 90TL terminal server series widgets.

The DECserver devices all left DEC and went to Vnetek (current home; formerly available at Cabletron and DPNG at various times) over a decade ago; check with the folks over there about access to the firmware.

And if this is a bug with the LAT host software and its interface into this DECserver, that's going to require a formal report to one or both Vnetek and HP.

The other option is to replace this DECserver with something more recent, using IP or such. There are options here, too.

But if you want to pursue this, you're going to have to provide a reproducer to the folks maintaining the boxes involved here.

[Antoniov.]

HOff,
I can't debuf a serial port like LTAxxx because it's a full OS controlled and managed port!
I simply send data into LTAxxx port.
I don't change ANYTHING in Decserver. I have both OpenVMS server connected to Decserver. Server AXP with OpenVMS 7.2-1 works, HP Integrity with OpenVMS 8.3 doesn't work.
Perhaps, HP should debug application.

Antoniov

[Hoff]

So there's no application here beyond PRINT? After specifically verifying the LT device and terminal settings, then contact HP; if that's the case, contact HP.

If there's an application sending data, that's something you'll need to investigate. I'm assuming there's an application involved here somewhere, either linked directly to the LT device or that submits the file to the printer. And if the latter, confirm the content of the files that work and the files that do not work.

>I can't debuf a serial port like LTAxxx because it's a full OS controlled and managed port!

Eh? I'm not sure why you think that's not possible. You need to see what data is being sent. Watch what's on the wire. Here, that's out on the far end of the DECserver. It's been my experience that watching the wire (breakout box or serial line analyzer or an improvised tap) is the best way to see what's really going on. It can be tedious, but can also provide invaluable evidence for debugging this.

>I simply send data into LTAxxx port.

More correctly (pedantically?), you believe you're sending that data. I've not seen confirmation of same.

>I don't change ANYTHING in Decserver.

This may or may not involve the DECserver. The DECserver is, however, a good spot to insert a tap and see what's going on with the serial line.

On no evidence, I'd tend to look at the application code involved here first. Either in

>I have both OpenVMS server connected to Decserver. Server AXP with OpenVMS 7.2-1 works, HP Integrity with OpenVMS 8.3 doesn't work.

With no disrespect intended, that the application works in one configuration does not indicate the code is bug-free or that the code will continue to work. The more that somebody believes something is bug-free (in the clear evidence of an existing bug), the more I'm inclined to suspect the code itself has a bug. The mantra of debugging (whether hardware or software) is to trust but to always verify.

>Perhaps, HP should debug application.

You can certainly pay somebody to debug the application for you, yes, and you can ask HP for that assistance. That's your choice. (Few folks here are HP, and likely fewer HP folks are in a position to volunteer to investigate your code. If you have an HP support contract here, you can choose to ask for assistance here.)

The old Ask The Wizard topic (1661) has a write-up on the common synchronization bugs, if you want to review the code for potential latent errors...

http://h71000.www7.hp.com/wizard/wiz_1661.html

[Volker Halle]

Antoniov,

did you ever provide a detailled problem description ? Maybe you should try to do so.

As far as I'm aware, flow control on the DECserver port is done by the DECserver itself, so I can't see, how the host operating system can cause a problem for port flow control.

You could turn off the remote serial device (printer ?) or unplug the cable, then try to write to the LTAn: device from OpenVMS. After some amount of data is sent via LAT to the DECserver, the write should hang, if flow control does work. You can try from both the Alpha and the Itanium system. Same behaviour ?

What kind of DECserver is being used ? What version of firmware and hardware ?

What is the 'application' writing to the LTAn: device ? A file being printed via LATSYM ? Or IO done directly to the LTAn: device from the application ? If 'data is lost', can you find out, which data from the application ist lost ? Data from the beginning of the data stream, the middle, the end ? Individual bytes or groups of bytes ?

Volker.

[Antoniov.]

Sorrry for late.
I was out of my office since today.

Here details:
1) I type
$ COPY MYFILE.TXT LTAxxx:

This command works on AXP V7.2-1 and doesn't work on Itanium OVMS 8.3

On Decserver side, the port has the following no defalut values:
flow control = DSR
signal control = enable
type = hard
access = remote


TIA

Antoniov

[Antoniov.]

Sorry I've forgotten some detail.
On HP Itanium V8.3 command works apparently but some data lost.
On the other side there is a barcode printer.
This printer work just with DSR/DTR flow, no XON/XOFF.

Antoniov

[Hoff]

That there is no problem description included here - as a problem description, this "doesn't work" is unfortunately and entirely insufficient detail - leaves me with little choice and little cogent contribution (beyond what's already been suggested around gathering details) other than to suggest that direct contact with HP support be made here.

Apply ECOs up to current. Then please call HP support, and work through this matter with the HP support team and with Vnetek or whomever is supporting the target DECserver device.

Somebody here is going to end up doing a configuration review and a serial line trace and possibly a LAT trace.