520 pts.
TELNET exit programs
Hello I am working on a TELNET exit program that will prevent people from getting in thru the PC RUN Command, whereby they type in telnet (I/P address of the AS400); ie telnet xxx.xx.xxxx. I recently downloaded the program DEVINIT2 to see if this would work. . Well, I have 2 issues with this program. a. Whenever I change the MAP QTXTSRC program thru SEU, and key in a specific user as one of the parameters, it does not work. Anyone can still get in thru the PC Run command. b. No matter what I change in the MAP program thru SEU, it not only affects the PC Run Telnet Command, but, it also affects client access. So, I not only lock a user out of the AS400 thru the PC run command, but, I also lock them out of the AS400 thru their local Client Access. So, they can not get to their AS400 thru client access, and the program is no good to me here. I am wondering if there is an alternative to the exit program that I am using, or, if someone is familiar with this particular program and can give me some hints as to what I may be doing wrong. Please advise -Nick

Answer Wiki

Thanks. We'll let you know when a new response is added.


You can look at this website.



There is no way for your AS/400 to know what process on a remote system is contacting any server. The telnet server only knows what comes across the telnet port, and every telnet client will send sockets data according to the telnet RFCs.

However, there are telnet, TN5250 and TN5250E (technically there are also 3270 protocols that can be accepted) standards such that additional data may be sent by more sophisticated clients. Note that the more sophisticated clients can also be configured to send only the data elements of the lower standards. E.g., a client capable of TN5250E might only connect as TN5250.

IOW, if you want to restrict to a specific TN5250E client such as PComm from iSeries Access, the best you are likely to do is to refuse connections for every client request that is configured to (or perhaps capable of) sending only basic telnet or TN5250 connection requests. In that case, simple Windows telnet could be rejected simply because it didn’t send a complex enough set of connection parameters.

Thorough reading of the telnet, TN5250 and TN5250E RFCs will tell you what each may send. This telnet article also references numerous related telnet RFCs.

The really serious trick is in having an isolated test environment. It is risky to have a test exit program that will return an Accept/Reject indication when you are uncertain how to react to all of the various parameter combinations. If the exit program says to Accept, then the session will be allowed regardless of correct password for example. (Or any password at all.) If you feel uncertain that your exit program correctly handles all request options, it is strongly recommended not to keep it active.


Discuss This Question: 2  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Piano
    Hello Thanks for your response, but, according to the documentation, this solution only works for O/S level V4R2 and V4R3. I failed to mention that this solution needs to work for version V5R4. Nick
    520 pointsBadges:
  • Gilly400
    Hi, Is it an option to revoke authority to or remove the telnet program on the PC's? Regards, Martin Gilbert.
    23,730 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: