TCPIP $QIO IO$_ACPCONTROL INETACP$C_HOSTENT_OFFSET

[Mark Daniel_2]

(No, I'm not shouting, just cutting and pasting :-)

It appears as if when resolving host address(es) from host name using INETACP$C_HOSTENT_OFFSET the $QIO IO$_ACPCONTROL call will fail returning an SS$_ENDOFFILE if insufficient storage if provided.

I would have thought SS$_RESULTOVF or similar would have been a more reasonable status (perhaps populating as much of the storage as was possible) and allowing this issue to be differentiated from a genuinely unresolved host and possibly mounting some sort of programmatic recovery.

Is this indeed the case or have I missed something in the documentation?

HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1
on a Digital Personal WorkStation running OpenVMS V8.2

[Richard J Maher · Accepted solution]

hi mark,

I get ss$_badparam (which is probably as good as any) Please see attached.

Given that that the structure can never exceed 65535 and is artificially pegged at syi$_maxbuf (minus o/head) , why not just give it a really big one? Once again, see attached.

Cheers Richard

[Mark Daniel_2]

Hi Dick,

I've given 9 points, not because it's got me any closer to to solving the issue, just for the trouble you've gone to coding this one up and/or the entertainment value of seeing working Cobol again after twenty years ;-)

I have attached my reproducer (in slightly more widely available C). Part of the issue may be with hosts that return multiple addresses. The en.wikipedia.org currently is returning some 16 when using INETACP$C_HOSTENT_OFFSET. Although my reproducer doesn't tease this out, it does show that when the data structure is too small I just get ENDOFFILE.

Thanks again.

[Mark Daniel_2]

Of course that should have been 14 (not 16) addresses!

[Richard J Maher]

Hi Mark,

I see your point. It doesn't look quite right does it. After re-reading the docs, I too would've expected ss$_resultovf or ss$_bufferovf. I even lowered MaxBuf, stopped/started UCX and created oodles of aliases and 1/2 doz address so that the hostent would be bigger than maxbuf but the ACP just seemed to trim it and gave me ss$_normal. Then I trimmed down the buffer to get ss$_endoffile again and it still gave me ss$_normal. I think you're right about it being specific to address, and it's not that fussed about alias names? Anyway, I too vote bug.

I don't have a box with TCPware on it to test at the moment, anyone know what statii that pops out?

> I've given 9 points,

I'm not sure about this whole points and hats thing. Is it rude/frowned-upon not to apportion points?

> just for the trouble you've gone to coding > this one up

No real effort, I had similar code around to cut and paste.

> and/or the entertainment value of seeing
> working Cobol again after twenty years ;-)

You gotta get out more! Mind you, I see that you're from Oz and since being back I'm starting to understand your surprise :-(

> I have attached my reproducer (in slightly > more widely available C).

I won't get into the old "my language can beat up your dad" argument but if one was using C then why wouldn't they use gethostbyname()? Anyone got access to the code for that? Do a lot of C socket people prefer the $qio interface?

Sorry not to be of more help, but hey it's good to talk :-)

Cheers Richard

PS> How do you get someone's e-mail address from their profile? Or can't you?

[Jan van den Ende]

@Dirk,

first of all: welcome to the VMS forum!


I'm not sure about this whole points and hats thing.

The 'hats' is the only reward system for ITRC, and frankly, it is just fun and little more than that.


Is it rude/frowned-upon not to apportion points?

Frankly, YES.
The Statistics, published weekly, assign a "thumb-down" to everyone with an assignment percentage below a treshhold (anyone knowing the exact percentage?)

More on the points system:
http://forums1.itrc.hp.com/service/forums/helptips.do?#28

Hey man, you are doing VMS. Enjoy! Have fun!

Proost.

Have one on me.

jpe

[Mark Daniel_2]

Hi again Richard.

Excellent idea (my lateral thinking must be on holiday :-) I don't have access to TCPware but I do to MultiNet (Process Software MultiNet V4.4 Rev A-X, COMPAQ AlphaServer DS10L 466 MHz, OpenVMS AXP V7.3).

(How I hate this ITRC HMI with a growing passion.)

I have modified my reproducer as attached. In this latest incarnation it ignores the returned status.

Under TCP/IP services an NSLOOKUP en.wikipedia.org produces:

Name: rr.pmtpa.wikimedia.org
Addresses: 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246
207.142.131.247, 207.142.131.248, 207.142.131.202, 207.142.131.203, 20
7.142.131.204
207.142.131.205, 207.142.131.206, 207.142.131.210, 207.142.131.213, 20
7.142.131.214
Aliases: en.wikipedia.org, rr.wikimedia.org

There are 14 addresses. And my modified reproducer:

1. 1024 bytes
1. OK! (268 bytes out) 14 hosts
2. 256 bytes
2. OK! (268 bytes out) 0 hosts
3. 4 bytes
3. OK! (268 bytes out) 0 hosts

Also 14 addresses. Under MultiNet:

Non-authoritative answer:
Name: rr.pmtpa.wikimedia.ORG
Addresses: 207.142.131.247, 207.142.131.236, 207.142.131.245, 207.142.131.206
207.142.131.214, 207.142.131.213, 207.142.131.204, 207.142.131.235, 20
7.142.131.203
207.142.131.205, 207.142.131.210, 207.142.131.246, 207.142.131.248, 20
7.142.131.202
Aliases: EN.WIKIPEDIA.ORG, rr.wikimedia.ORG

Again 14 addresses. The reproducer:

1. 1024 bytes
1. OK! (221 bytes out) 14 hosts
2. 256 bytes
2. OK! (221 bytes out) 14 hosts
3. 4 bytes
3. OK! (221 bytes out) 14 hosts

It claims 14 addresses *but* I'm not sure what MultiNet is up to because it *seems* to be ignoring the size of the supplied data structure!

I can imagine something going on in HP TCP/IP Services though, that I can't find in the documentation. It looks suspiciously like HP's implmentation returns the number of bytes *required* to complete the service (even though it obviously failed for any particular instance).

Perhaps HP TCP/IP is exhibiting some undocumented behaviour and MultiNet is buggy, or at least dissimilar in behaviour to the HP TCP/IP it's eumulating? TCPware instance would be interesting.

BTW.


> I have attached my reproducer (in slightly
> more widely available C).

I won't get into the old "my language can beat up your dad" argument but if one was using C then why wouldn't they use gethostbyname()? Anyone got access to the code for that? Do a lot of C socket people prefer the $qio interface?


I chose my description carefully :-) I wasn't wishing to start a "mine's bigger than yours" thread ;-)

Why $QIO? Meshes nicely with asynchonous ASTs. You could say the were built for each other.

Oh, and apparently welcome back cobber (your name seems familiar though I'm not sure from where).