DEC MessageQ v3.2 and TCPIP v5

[Gregg Parmentier]

We're using DEC MessageQ v3.2 for communication between applications on multiple nodes. DEC MessageQ is communicating between these nodes using TCPIP via UCX 4.2. When I upgrade the TCPIP to v5.1, that connection doesn't work.

I can make DEC MessageQ work with DECnet, but we may want to connect to some unix servers in the future for application migration.

Is there a way to make DEC MessageQ v 3.2 work with TCPIP connections under TCPIP v5.1 and later?

[Hoff]

BEA now owns the MessageQ product.

Upgrading to the TCP/IP Services V5.1 release seems somewhat unusual; that's an old and unsupported release, and there are definitely ECOs for that release. Is this part of a particular OpenVMS upgrade? I'd thing that 5.4 or 5.6 would be a better choice, while you're (probably) upgrading OpenVMS and upgrading TCP/IP Services.

Do consider looking around over at the BEA site, or directly asking the BEA folks.

http://www.bea.com

I'd expect you can get BEA MessageQ working with Unix when you need to, but you might be asked to load the current TCP/IP ECO, or for a TCP/IP upgrade (and possibly an OpenVMS upgrade) should you run into issues with your current V5.1.

[marsh_1]

gregg,

as far as i know dmq v3.2 is unsupported now, the latest bea version v5.0 is stable and works , you should be able to just recompile your apps with the new version and go, although entries for the queue names in v5.0 are case sensitive.

[marsh_1]

sorry to clarify, the queue names in dmq$init.txt are case sensitive.

[David B Sneddon]

We are using DmQ V3.2-B46 with TCP/IP V5.6-ECO2
with no problems. Do you have any specific details
rather than "doesn't work"?

Dave

[Gregg Parmentier]

Here's a copy of the log. I tried relinking all of DMQ after the upgrade, but the error remains the same.

I also have no idea what became of the distribution media here, so if there's something specific to the install that selects certain files depending upon the existing TCIP stack, I'm behind the eight-ball on that.

[Hoff]

I'm thinking that there's a fundamental IP network error or configuration error here somewhere. That's the only thing I can line up with your reports.

Based on the attached text file, the connection appears to be failing because something is looking for and not finding an unspecified logical name. (MessageQ isn't particularly helpful here with its error message; not listing the logical name that it is looking for is Not Helpful.)

Assuming TCP/IP Services has been configured and started, start looking at your logical name definitions.

If TCP/IP Services has not been configured and/or started, configure and/or start it now.

A Google search for MessageQ and gethostname shows the DMQ$TCPIP_LD_NAME logical name as "Override the default hostname returned by a call to gethostname(). This logical name can be used to define an alternate interface for the linkdriver activity". Which looks to be potentially useful here, though I don't know off-hand if your version has these.

The C gethostname() call is documented as returning the translations of the logical names (and current C RTL gethostname() calls are compliant with the TCP/IP Services logical name definitions), though there's a chance here that MessageQ has gone directly after the old logical names itself; that MessageQ is translating the values directly. Which means you should check for existing definitions of TCPIP$INET_HOST and TCPIP$INET_DOMAIN, and (if these translations are present) then check for the old names UCX$INET_HOST and UCX$INET_DOMAIN and -- though I don't usually recommend doing this -- define those, using f$trnlnm on the values you do have.

The versions I've looked at define both sets of logical names, starting at TCP/IP Services V5.0. MessageQ V3.2 is sufficiently ancient it may be looking at old names. But I'd expect newer TCP/IP Services to have defined what MessageQ is looking for.

If you're so inclined, SEARCH the MessageQ files for UCX$ strings, and see what it's looking for. (OpenVMS unfortunately doesn't have a strings command, but the SEARCH command can rummage through executable images.)

I'd look at why MessageQ and TCP/IP Services aren't playing well together here.

BEA documents V5.x as working with various Unix boxes, so there's some other issue there with either MessageQ or with the local IP network configuration that you'll want to get somebody to look at. If you're paying BEA for MessageQ or HP for OpenVMS support, do consider ringing them up.

Stephen Hoffman
HoffmanLabs LLC

[Gregg Parmentier]

Logicals got rid of the errors, thanks for the pointer.

Now the program just ends without any indication of why, and wthout even attempting a tcp connection:-)

I hadn't checked before, but I do see my HP contract has MessageQ support (I really wasn't expecting it), so I'll pursue things that way.