Programming dedicated LAT application ports on Itanium

[twhjr]

Greetings,

VMS 8.3-1h1 UPDATE 10

I have an application I am porting from an Alpha to Itanium that uses a dedicated LAT application port. My problem is that when I post my initial read to the port a 0x1c is returned in the status (IOSB is 0) which is EXQUOTA. I bumped all of my process quotas (AST, ENQ, TQE, BIO & BYTLM) until authorize told me that the numbers where too big… I have steped through the code with the debugger and monitored the process quotas and I cannot see any quotas being over utilized. It has been a long time since I programmed any LAT ports, it was on a VAX, so I am not sure if I am missing anything simple?

NOTE there is no actual terminal server on the Itanium development system, however, there is also no terminal server pointed to the Develoment Alpha and I do not get any errors. I also have another application that runs on the Alpaha and Itanium that only communcates with one LAT port so when it hangs a READVBLK it does a QIOW. The application that is having the problem is listening to four LAT ports and is supposed to hang 4 reads, one to each port, then hybernate and wait for the ASTs to fire.

$ lcp create service/identification="TAS Communications"/application/log TAS
$!
$ lcp create port /logical=(name=TAS_PORT'portNum', table=LNM$SYSTEM)/dedicated/log
$ lcp set port/service=TAS TAS_PORT'portNum'
$!
$ set term/perm/hostsync/nobroadcast/ttsync/eight_bit/hangup/type_ahead-
/edit_mode/line_editing/disconnect/insert/ansi_crt/autobaud/nodialup -
TAS_PORT'portNum'
$!
$ set security/protection=(s:rwlp,o:rwlp,g:rwlp,w:rwlp)/class=dev TAS_PORT'portNum'

LATCP> sho port
Port Name Port Type Status Remote Target (Node/Port/Service)
--------- ----------- ------------- -----------------------------------------
_LTA5089: Ded. (NonQ) Inactive //TAS
_LTA5092: Ded. (NonQ) Inactive //TAS
_LTA5095: Ded. (NonQ) Inactive //TAS
_LTA5098: Ded. (NonQ) Inactive //TAS
_LTA5101: Ded. (NonQ) Inactive //TAS
_LTA5104: Ded. (NonQ) Inactive //TAS
_LTA5107: Ded. (NonQ) Inactive //TAS
_LTA5110: Ded. (NonQ) Inactive //TAS
_LTA5113: Ded. (NonQ) Inactive //TAS
_LTA5116: Ded. (NonQ) Inactive //TAS
_LTA5119: Ded. (NonQ) Inactive //TAS
_LTA5122: Ded. (NonQ) Inactive //TAS
_LTA5125: Ded. (NonQ) Inactive //TAS
_LTA5128: Ded. (NonQ) Inactive //TAS
_LTA5131: Ded. (NonQ) Inactive //TAS
_LTA5134: Ded. (NonQ) Inactive //TAS


//
// Assign communication channels for modem port names to DEV channels.
//
status = sys$alloc(&portName_desc[index], 0, 0, 0, 0);
if((status & 1) || (status == SS$_DEVALRALLOC)) {
status = sys$assign(&portName_desc[index], &DEV_chan[index], 0, 0);
if(status & 1) {
//
// Enable CTRL+Y and CTRL+C ASTs on DEV devices.
//
CTRLindex = index + LINE_BREAK;
status = sys$qiow(EFN$C_ENF, DEV_chan[index],
IO$_SETMODE|IO$M_CTRLYAST,
&DEViosb[index], 0, 0,
Hangup_Handler, CTRLindex,
0, 0, 0, 0);

if(status == SS$_NORMAL) {
//
// Post first read AST on DEV device.
//
DEVinfo[index].prompt_index = 0;
Port_Status[index] = 1;

strncpy(DEV_buf[index], "\0", DEF_IN_BUF_SIZE);
strncpy(LOG_buf[index], "\0", DEF_OUT_BUF_SIZE);

status = sys$qio(EFN$C_ENF, DEV_chan[index],
IO$_READVBLK|IO$M_NOECHO,
&DEViosb[index],
Port_Connection, index,
DEV_buf[index], DEF_IN_BUF_SIZE,
0, 0, 0, 0);

if(status != SS$_NORMAL) {

[twhjr]

Greetings,

OK, folks here is some more interesting tid bitsâ ¦ If I use set host/lat to get to my port I get the following:

ENG641> set host/lat/node=eng642/dest=tas_port01 tas
%LAT-F-CONFAIL, connection to TAS not established
-LAT-F-LRJINUSE, port or service in use
-LAT-I-END, control returned to node ENG641

I can, however, connect to the repair port and run the application that is hanging on a QIOW:

ENG641> set host/lat/node=eng642/dest=repare_port01 repair
%LAT-S-CONNECTED, session to REPAIR on node ENG642 established
%LAT-I-TODISCON, type ^\ to disconnect the session
Enter your name (ex. John Doe) --> fred
Enter your business name (ex. All Mechanics) --> freds repair

Now I just have to figure out what is using the ports for TAS.

Have Fun,
twhjr

[John Gillings]

twhgr,

First comment. LAT is dead. You'd be much better off reimplementing whatever you're doing using a current protocol.

Second, did this ever work? I don't believe it should have. LAT application ports are primarily OUTBOUND. That is, one external physical serial device, like a modem or printer services multiple back end nodes any of which can INITIATE a connection to the device and communicate with it. The key here is the host establishes the connection to the LAT device.

In your example above, there is no initiation. Your LCP commands create the device, association, and network path, but your code just opens the device and attempts to read, without first establishing the actual connection.

Consider. Suppose there were several nodes which execute your code at the same time, all sitting waiting for input. Now, a character arrives at the LAT device. How does it know where to send it if none of the nodes have established a connection? There's no way for the LAT device to know who, if anyone, is listening.

A "supported" application would explicitly issue $QIOs to the LAT port to establish the a connection before attempting to read. (I say "supported" in quotes, because nothing to do with LAT has had any serious level of support for at least a decade).

Sometimes you can get away with an initial WRITE operation to the LAT device. This may implicitly establish a connection, but technically, it's not supported, and it assumes the LAT device will tolerate unsolicited output.

I don't know why you're getting the x1c status, but until you've got a workable program model, it's not really relevant.

Again, I stress that writing LAT code today is like storing your programs on punched cards. Please investigate more appropriate mechanisms.

[twhjr]

Greetings,

MY god man can't you read... This has been working on the alphas for over a decade and it still works. Many years ago this was a very common practice.

It is a customer requirement and I have less than a week to make this interface work.

If you have no constructive answers please do not take up any more of my bandwidth...

Have Fun,
twhjr

[John Gillings]

twhjr,

This IS constructive comment...

If this code worked, it was a fluke. If you don't explicitly establish a LAT connection from your application, there are no guarantees that it will work as you expect.

You're reporting that the code doesn't work, and I'm explaining to you why not.

Moving code from one platform to another will often expose latent errors or invalid assumptions in your code. Sorry if you don't like that answer, but if you want to make it work, you'll need to correct your code.

See Chapter 5 of the I/O Users Reference Manual, in particular Section 5.3.4 LAT Port Driver QIO Interface.

If you can't find a $QIO with function code IO$_TTY_PORT!IO$M_LT_CONNECT somewhere, then your code is wrong. There are a few other calls you need to make as well. See the IOURM for full details.

You MAY be able to get around the problem by issuing a WRITE operation on your port before your READ. This MAY implicitly establish the connection. It MIGHT be a quick and dirty fix for your immediate problem, but long term you should fix your code.

I worked in the Digital/Compaq/HP Customer Support Centre for many, many years. I've seen this symptom many times, and had the discussion about how to communicate with LAT application ports with dozens of programmers. The answer is always the same. Conform with the way LAT was designed to work, and your code will work. Try to take shortcuts and it MIGHT work, but it might not. Don't complain if it breaks. Fix your code.

>Many years ago this was a very common practice.

Perhaps so, but that doesn't make it correct, nor does it make it work. Think about what I said. Take N nodes, each of which posts an outstanding READ to a LAT port mapped to the same physical device. How does the device know where to send data? From the perspective of the host there's only one destination, but from the LAT device there are potentially many. You need to resolve that by explicitly establishing a connection from a host to the LAT device.

latin motto #2 of customer support:

Insunt interdum menda in eo quod est efficax

translated

There are sometimes flaws in that which is efficacious

in other words

just because it (seems to) work, doesn't mean it's correct

[Craig A Berry]

This is a really odd construct:

strncpy(DEV_buf[index], "\0", DEF_IN_BUF_SIZE);
strncpy(LOG_buf[index], "\0", DEF_OUT_BUF_SIZE);

If you're trying to null terminate ASCIZ strings, this may kinda sorta work but definitely looks like it was written by someone unfamiliar with C. If the intent is to zero-fill the buffers (which would make more sense in this context) then the code as written isn't doing that. Compare the docs for strncpy and memset and use the latter.

Just because the code has been working for over a decade doesn't mean it's correct nor that latent bugs in the code aren't the immediate source of the problem.

[Bob Blunt]

twhjr, while I can't question the code you're writing or attempting to use there are still situations where LAT should work as long as your environment supports it. There have been other facilities that have proven to need work after the port to Integrity. When I had access to a small rx26xx server in our office lab I had tested all the older networking giblets and had successfully run that system as a DECnet Phase IV system with LAT and TCP/IP. I only toyed around with some $ SET HOST/LAT around the lab and it seemed to work.

At the same time I was using the CA version of Console Manager on Alpha to manage the consoles but an Integrity solution wasn't available yet. So I wasn't able to test a product that could be configured with LAT connections to terminal servers to validate that part of LAT. Personally? I'd look around for some simple examples of creating and connecting LAT ports from what were the DECUS libraries in the hope that you can find something that works on Alpha and is simple enough to get it working on Integrity.

Like I said, I can't check your application code to say how well it'll work but I would hope that you could find some examples that can help you. And if the problem continues to generate the errors you're seeing I'd definitely take it to HP. I don't remember LAT becoming unsupported BUT I also don't know how well those features got tested if at all. Some basic stuff worked for me but thats a far cry from what you're trying to do.

bob

[Robert Gezelter]

twjhr,

I would want to take a careful look at the code. It is not uncommon for latent bugs to be unearthed during a port. I have programmed LAT from the host side quite a few times, and admittedly the error returns can be cryptic.

One thing I would also check are the LAT node settings on both systems.

My apologies for terseness, but I have to get ready to give a presentation later.

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

[Craig A Berry]

I said:

<<<<<
strncpy(LOG_buf[index], "\0", DEF_OUT_BUF_SIZE);

If you're trying to null terminate ASCIZ strings, this may kinda sorta work.
>>>>>

Actually, it won't. strncpy copies the source string up to but *not including* the null terminator. So these calls do precisely nothing because the source strings have nothing in them but a null terminator. May or may not have anything to do with your problem, but code that clearly doesn't do what it was intended to raises a red flag.

[Hoff]

Old code is quite often buggy, and the older the code, the more and weirder the bugs, and usually buggy in some creative ways, and old code seldom includes decent embedded diagnostics and embedded debugging support. VAX code? Usually buggy. Ported code? Buggy. Working code? Yep; buggy.

(Some of the older C lurking around is also built with /STANDARD=VAXC, and seemingly as a way to suppress all the nasty little coding errors that the newer compilers are finding in the code, but that's another discussion.)

I can't tell if that code here is correctly using the IOSBs. Errant IOSB processing can cause EXQUOTA errors.

C code such as this is seldom auspicious:

>if(status != SS$_NORMAL) { ...

That's quite often the footprint of a broken status check. (It should be the $VMS_STATUS_SUCCESS macro or a low-bit test, as there can be more than one successful return status value from various of the system calls.)

This C code:

>strncpy(LOG_buf[index], "\0", DEF_OUT_BUF_SIZE);

Definitely broken. Was memset intended there?

Is it possible that the $qio is getting (unintentionally) called multiple times; if the synchronization is broken, then a run-away loop is feasible and can trigger weird EXQUOTA errors. Depending on how you've used the debugger here (and how this code is structured) it might not be the first $qio call that tosses the error.

You'll want to test with a real terminal server, too.

Check the MAXBUF system parameter on both the old and the new boxes. The default needs to be bigger than DEF_IN_BUF_SIZE and DEF_OUT_BUF_SIZE here.

And VMS application code almost always stinks at error logging, too. No ties into syslog or other tools commonly used for centralized logging.

The usual suspects for hosed serial communications are:

MIN_TTY_TYPAHDSZ = 8192
MIN_TTY_ALTYPAHD = 8192
MIN_MAXBUF=16384

I don't recall if the TTY buffer stuff also hits the LAT ports, though.

It's commonplace to add minimum quota checks and minimum parameter checks into some applications, and particularly if the code is used on a variety of systems.

And $DIETY, it's FREE TECHNICAL HELP you're getting!