LAT port cannot work on IA64

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