I’m not 100% sure this is the reason/answer, as I am using local TCP/IP when using the QSECOFR profile and I have no problems, but could it be that when the machine was installed/configured that (I can’t think of the value/configuration name it is in a “Q” value file in the machine, I believe it is possible to disallow QSECOFR profile accessing the AS/400 on any terminal other than a hardwired, twinax 5250 terminal locally connected to the machine (in computer room, or near the machine).

I am getting an error message when I try to connect to the i5 with a Windows based query application.
QSECOFR user profile is not allowed in TCP/IP socket mode!

First, is that the error message that you see (“QSECOFR user…”)? How do you see it? I’d guess in a popup message box, but maybe not. What is the “query” application? Are you attempting to use SQL to retrieve rows from tables? I ask because of your next statement:

…it might has something to do with an FTP restriction on i5 side.

A FTP restriction shouldn’t have any connection to a “query” application that uses SQL. This might be misleading everyone and might need to be ignored.

I also tried another profile which has higher authority level than the QSECOFR profle(QSECADM).

No profile can have ‘higher authority’ than QSECOFR. You aren’t even allowed to remove any of the special authorities of QSECOFR. Technically, it’s probably a good idea that QSECOFR is restricted. QSECOFR should be reserved only for cases where IBM instructions direct you to use it. There is an extra risk of damage to the profile when it is in use (via power outages, hardware failures, etc). Recovery from damage to QSECOFR can be a difficult process, especially at sites where secondary security officer profiles haven’t been created.

And if secondary security officers have been created, then they should be used rather than QSECOFR.

Tom