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.

[Jur van der Burg]

This code is seriously broken indeed. If you do a $qio you need to check the return status from that qio, which is done. The thing that is NOT done is a check for the right status in the iosb, specifically iosb[0]. Without that you never know if the call succeeded or not.

Make sure you check that status and print it if the low bit is clear, it may give a clue.

Jur.

[Robert Gezelter]

Antoniov,

I am starting back at the beginning.

There are TWO status returns that must be checked when doing ANY of the QIO and related functions (e.g., QIO, ENQ, GETJPI, etc.). The first, returned as a function return from the call itself is whether or not the directive was processed successfully.

Getting a successful result in the function return implies nothing about the eventual result of the request. The only result that matters is the contents of the IOSB status value. Buffer contents (and the remainder of the IOSB) are only valid in the context of the IOSB status.

I have seen many cases where the code erroneously confuses the two status values. When something does not work, usually the IOSB has not been checked correctly.

In years past, I have seen many of these and slightly similar cases. Way back (RSX-11M Version 3-3.1), I found a problem in a piece of code that had done a QIO (without a wait) and worked. It turned out that the Version 3.0 terminal driver forced a wait during terminal IO, the Version 3.1 driver relaxed that provision, causing the code to fail. It was the code, not the underlying OS. Wait was always documented as obligatory.

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

[Hoff]

The sharing of the $status variable also looks like a way to hide a good bug or two; it works, so long as the check and the checked operation are always contiguous, and there are no ASTs or asynchronous operations around.

This:

if (($status & 1) != SS$_NORMAL) { failure code }

is an odd construct. It creates correct code, but I don't think it was what was expected, and it is unlikely to work for any condition other than SS$_NORMAL. The following is a more typical approach:

if ( !$VMS_STATUS_SUCCESS( $status )) { failure code }

dviread() treats one successful condition as success, and all other successful conditions and all errors as failure.

As I had guessed in my first reply, iosb is not handled correctly here which means the code is unstable at best. Others have commented on this. This is a central problem with this code; it's just not known if this code is stable.

The UpdLog function is not logging the interesting part of the iosb, either. For failures, the contents of iosb[0] is far more interesting than iosb[1].

Some of that code would be better in a state machine, whether using lib$table_parse or otherwise. Large if-then-else-if-else-then-if sequences just never work out.

Depending on what you are doing here, connections out and even modem dial-out is possible with the SET HOST /DTE command that is available at DCL. (Though I don't know what goes in the "{tailored code}" section.)

Volume 4B? That's a documentation reference I haven't seen in a while. This code was probably ported across from OpenVMS VAX, and most VAX boxes are typically uniprocessors and are generally much less asynchronous than are Alpha or Itanium boxes.

The code has a memory leak in GetJParm().

Continuing after a malloc failure in GetJParm() -- attempting to continue after any malloc() failure in any code anywhere -- is generally a bad idea.

[Antoniov.]

Hi Guys,
code was ported from old VAX to AXP in nineties and now I wanto to port on IA64.
Now I change code and test iosb[0] as most of you said to me.
I'll report you the result.

Thanks.

Antoniov

[Ian Miller.]

A small point not yet mentioned is that zero in the IOSB means the QIO has not completed. After the $QIO code has completed its checks and before the I/O is started the IOSB is zeroed.

[John Santos_2]

In the original post, Antoniov said he was using sys$qioW, not sys$qio, so he shouldn't be seeing a zero in the IOSB unless there is something seriously wrong. If the I/O got queued correctly then the IOSB should get cleared initially, and then get set at I/O completion. The QIOW should not return until then. It sounds from the discussion like the I/O is getting queued (success status returned by the sys$qiow), but Antoniov is seeing 0 in the IOSB, so something either cleared the IOSB again after the I/O completion set it, or something tricked QIOW into returning early.

QIOW (and the xxxW variants of may other system services) calls an implicit sys$synch to wait for completion. I think, but am not certain, that sys$synch spins on the IOSB, so if something else sets the event flag, sys$synch won't get fooled. Perhaps something else put something into the IOSB, then set the event flag, and then *cleared* the IOSB again. (Do you have any async I/O or sys$getxxx calls running in the background?)

So what I would look for is 1) a typo (specifying the wrong IOSB in the call or accidentally sharing it with some other call), 2) a typo where you are actually calling sys$qio instead of sys$qiow, 3) creating the IOSB on the stack and then returning before it is used or examined (this is a common bug in asynchronous code, IMHO, but is unlikely here, since Antoniov is using QIOW and appears to be creating and using the IOSB locally), 4) sharing an event flag (though I think $synch defends against that), or 5) accidently using the asynchronous version of some other system service elsewhere in the program (e.g. sys$getjpi, sys$getdvi, etc. instead of sys$getjpiw or sys$getdviw.)

It's most likely a bug that has always been there, but was rarely or never seen on VAXes or Alphas because the timing was different. I always enjoy smashing a long-standing bug, so you have this pleasure to look forward to! :-)

HTH

[Jur van der Burg]

He said that the iosb contained 0, but that was iosb[1] and not iosb[0].

Fwiw,

Jur.

[Antoniov.]

My Dear Friends,
I changed in source code the check for iosb[0] instead of $status. Now the return status is 0x22C that's mean time-out.
So the return code is true but I don't yet solve.
I carefully watched this old code (from VAX); I didn't remember that code set DSR flow control. Now I try with standard XON/XOFF control and I'll report you the result.

TIA
Antoniov

[John Gillings]

re: Hein,

>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.

Normally I'd agree with you. I/O should be device independent, so you don't need to care about the physical device. However, LAT is different because there LAT device exists even when there is no connection to the physical device.

So, consider the serial port out on the terminal server. There may be many LTA devices pointing at it, from any number of nodes. Numerous processes may have issued READ $QIOs against one or more of those LTA devices. Suppose a character appears at the port, where should it be sent?

Some event must initiate a connection between the LTA device and the terminals server. Perhaps posting a READ should create the connection, but it doesn't. A design decision we're stuck with. A WRITE operation will create the connection, so this type of application will work (but unsupported) if the initial operation on the LTA device is a WRITE.

That's why in the general case you need the IO$M_LT_CONNECT.