LAT port cannot work on IA64

[Antoniov.]

Hi to All!
I'm porting my application from AXP to IA64. It's Ok but I met a weird trouble using LAT port and DecServer 90TL/TM.
My software opens the stanndard input LAT port TT using sys$qiow service. On AXP, application reads input characters but on IA64 it reads null bytes and doesn't read the right characters.
The DecServer is the same for both server (AXP and IA64).
Can somebody help me or else tell me something about this trouble?

TIA

Antoniov

[Robert Gezelter]

Antoniov,

Come now! Without the source, it is impossible to know what is the problem?

What error codes are coming back?

- Bob Gezelter, http://www.rlgsc.com

[Antoniov.]

Thanks Robert.
Application is written in C. Source is too complex to download.
I use sys$qiow service in order to read standard input port. Return status is 1 that's mean Ok but input buffer contains null character instead input key.
The same application works on AXP.

Antoniov

[Robert Gezelter]

Antoniov,

First, the attachment on the last entry in this thread does not appear to related to the thread (at least, there is no reference to QIO).

While I do not have my rx2620 online at this instant, I am pretty sure that I have used LAT and that it worked normally.

Without the code, it is difficult to do more than randomly guess. Can you create a small reproducer for the problem?

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

My first assumption with cases like this is always that my code is broken. Always.

The OpenVMS Alpha and OpenVMS I64 operating system code sees a whole lot of use and a whole lot of testing at a whole lot of customer sites, and thus Occam's razor points toward my code. Sure, there have been bugs in OpenVMS. But the number of those bugs is dwarfed by the numbers of bugs in application code.

Accordingly, I seek to prove it's not my bug.

And returning low-bit set (odd) as a condition status from sys$qio[w] does not mean that the $qiow call worked. It means that the $qiow call was successfully queued. What's in the IOSB?

And that the code works perfectly on OpenVMS Alpha does not mean the program is bug-free. I've seen bugs in OpenVMS itself that were day-one bugs; decades old. There are some cases around with bugs in code that are older, too -- somebody stumbled into a 33+ year old latent bug in yacc not long ago.

BTW, that C code that was attached probably was not what you intended to post. Somebody was looking at localtime() with that particular source code example.

[Paul Jerrom]

I had a similar problem porting from Alpha to IA64. In my case it was a DCL script reading from a LAT port - error was TNS (terminator not seen) and no characters were read. After several months of VMS engineering effort it was determined to be a problem with the sysgen parameter MAXBUF - I had to increase the Alpha value of 8K to 9K on IA64. After that, no more problem.

Have fun,
PJ

[John Gillings]

Antoniov,

LAT serial connections established from the host end are supposed to be created using LAT port driver $QIOs. See Section 5.4.4 of HP OpenVMS I/O Userâ s Reference Manual.

Now, here's the rub. It is often possible to set up a LAT device with LATCP and access it just like a real terminal. This is not supported. Everything apparently "works", and a program written this way may well have "been working for years". HOWEVER, that doesn't mean it's correct, and it doesn't mean it will continue to work, especially when fundamental things like the hardware platform change.

If your code is simply $ASSIGNing to a LAT device and issuing reads and writes, you may need to modify it to use the supported interface. Supported code will have $QIOs with function codes like IO$_TTY_PORT!IO$M_LT_CONNECT.

Just in case you missed it... if you don't see IO$M_LT_CONNECT, I don't care how long your application has been "working". If it's not using the correct API, it's been broken all along. It's just been looking for time and place to demonstrate it.

Write a cut down example, and make sure you check the IOSB.

[Hein van den Heuvel]

Disclaimer... This is a kneejerk reaction with no study of example or details provided and about a subject I have no acttually looked at for over 15 years.

John wrote>> "If your code is simply $ASSIGNing to a LAT device and issuing reads and writes, you may need to modify it to use the supported interface. Supported code will have $QIOs with function codes like IO$_TTY_PORT!IO$M_LT_CONNECT."

John, you have been exposed to OpenVMS Engineering folks too long. It has poluted your thinking. I'm sure you are techinally correct, but if you are, then IMHO OpenVMS is all wrong.

Why would an application need to know whether a terminal is 'real' or a 'lat'? Surely it should just 'work' on a basic level?
Yeah, if you want to do lat-things then by all means require the IO$_TTY_PORT!IO$M_LT_CONNECT mumbo-jumbo.
But a basic read or write write QIO either just work or completely fail from the get go. Any other behaviour is an OpenVMS weakness, not an application bug.

Antoniov... are you sure you posted the right reproducer?

Besides the obvious print format error, it contains one very dubious statement:

for (iDoNothing=0x0FFFFFFF; iDoNothing; iDoNothing--); /* Perdi un po' di tempo */

The classic CPU time waste attempt.
Totally unpredictable an unportable.

As far as I am concerned, a compiler can replace this with "iDoNothing = 0" (which then ironically means that iDoNothing is now really true :-).

HP C V7.3-018 on OpenVMS IA64 V8.3 generated a 2-bundle tight loop for this.

On an HP rx2600 (1.40GHz/1.5MB) that still takes 1/2 the time it takes on an AlphaServer DS10L 466 MHz. On an other chip it may take much shorter, and if that delay was really needed, it might no longer be long enough.

fwiw,
Hein.

[Antoniov.]

Hi,
I submited wrong code.
After sys$qiow (function dviread), I checked for success status; iosb contains null character (0x00).

Antoniov

[Antoniov.]

Hoff,
I agree my code is broken, but I don't know where is wrong.

Paul,
I hope you're right. MAXBUF is 8192 on target system. Today I'll set 16384 and I'll see what happens.

John,
I don't know if standard input is LAT. May be, I read from real serial port, i.e. TTA0:
At the moment, I prefer not use IO$M_LT_CONNECT.


Hein,
I submitted a testing code. I also have another trouble that's not important now.