... then the <unknown_name> part is usually one of three things:
the name of a function that is built in to the program
the name of a standard library function
the name of a system call
If you run "man <unknown_name>" and it returns a man page of section 2, it is a system call; if it returns a man page of section 3, it is a library function. In both of those cases, the next step is to read the description of the function/system call in order to understand what it is trying to do, then skip to the ERRORS section of the man page to see the descriptions of possible errors. The descriptions on the man page can often be more verbose and helpful than the terse one-line log messages.
If "man <unknown_name>" produces no results, then <unknown_name> is probably an internal function of <program_name>, and the only way you can know more is by viewing the source code of the program or by contacting the people responsible for the support for that program. (In the case of HP-UX telnetd, that would have meant opening a support call to HP.)
But in your situation, "man getmsg" will give you a getmsg(2) man page. However, none of the listed error codes nor their descriptions seem to be a good match to the "no data" error message.
Everything after this point is just an "educated guess" by me:
According to the getmsg(2) man page, this is about STREAMS-based files. This is probably the mechanism inetd uses to hand over the data of incoming connections to telnetd. According to the man page, a STREAMS message has a control part and a data part. "No data" would mean that the message had no data part at all, while telnetd expected at least some data.
The next problem is, what might have caused that?
My first guess would be that your system has been port-scanned, causing inetd to register an incoming connection to the telnetd port. But as the purpose of the connection was just to detect that the telnet service exists on your system, the connection was closed (or was not even fully established in the first place) without exchanging any data at all.
To confirm this theory, you would need to find a test server that has telnetd enabled and the same patch level as the server that produced the log message, port-scan it using several different methods, and see if it causes a similar messages to be logged. (If you are using a tool like nmap for port scans, you should know that only TCP-type port scans are relevant with telnetd.)
Another possible cause is a network monitoring system that periodically tests the availability of the telnetd service on your server. But if that was the case, messages like this might occur regularly and you would probably know that the message started to appear exactly when the monitoring system was installed and/or configured to monitor your server.
The worst possibility is that your server is being attacked, and this message is a result of the attacker abusing the telnet protocol in some unexpected way, causing telnetd to log a debugging-style error message.
You might want to check the patch level of your server: as port-scanning and network-based monitoring is becoming more common, operating systems are sometimes patched to handle port-scans better. If your system is not up to date, updating it might make the error message more understandable or remove it altogether.
