Common problems
- Diagnostic messages are not being printed to the appropriate file.
- The diagnostic messages are printed out with the use of syslogd. Ensure that the syslogd is currently active by checking for /etc/syslog.pid.
- If syslogd is active, ensure that the file where the output is sent is currently allocated. Syslogd creates the file if it is started with the -c runtime option. z/OS UNIX Telnet uses local1.debug for logging messages. Ensure that the syslog.conf file contains an entry for local1.debug or the *.* default file. See the z/OS Communications Server: IP Configuration Guide for more detailed information about syslogd.
- Ensure also that the specified file exists. Ensure that the permissions on the file are at a minimum 666.
- Make sure you specify -t or -D all, or -t and -D all, as the z/OS UNIX Telnet options in /etc/inetd.conf.
- Use of the arrow keys.
The arrow keys are not functional in raw mode. This is AIX®-like behavior, except that, in AIX, the arrow key produces peculiar characters such as ¬-B on the screen to let the user know not to use arrows. Under rlogin, the cursor moves to where you would want it and correction is allowed, but the shell also treats these characters as part of the original command.
- The keyboard appears to be locked and the user cannot issue commands.
When executing UNIX-type clients (for example, AIX), if the -k option is specified for Telnet in inetd.conf, Telnet does not allow kludge linemode (see Setting up the inetd configuration file). UNIX clients require character-at-a-time mode to process correctly. If you remove the -k option from the parameters, then the software processes correctly.
If this does not work, run tracing -t D all. Look for Ept to determine what the exception conditions are for the pty. The number of bytes should equal four. Verify that the exception conditions identified are processed by the TN3270E Telnet server. (Check EZYTE67I messages for more information; see Figure 1.)
- EDC5157I An internal error has occurred, rsn=0b8802AF.
The 2AF of the reason code signifies that the user did not have the proper authority to execute the command. This might result in either the user system having BPX.DAEMON authority set up in its environment, and the proper authorities have not been issued to the user. Another result might be that the user does not have super user authority, which might be required to issue some of these commands.