QTVOPNVT using an IP address

[Guest.Visitor]

Has anyone used the QTVOPNVT api to work using the IP address as a parameter? I have the api working (on the default connection) but can't use the IP address or a user name and password as parameters. I am programming in C. Thanks for any help.

[Guest.Visitor]

What type of problem are you having? If you wanted to use an IP address of 0.0.0.1 you would use an argument such as x'0000000100000007000000080802000100000001' for session initiation information where x'00000001' means 1 variable length record; x'00000007' means key 7; x'00000008' means length of data is 8 bytes; x'08' means the network address size is 8 bytes; x'02' means IP; x'0001' is the TCP port; and x'00000001' is the Internet address. Using this to start a session and calling QDCRDEVD to determine the address used for the session then returned 0.0.0.1. Be aware that when using multiple variable length records, each record must start on a 4-byte boundary (see Format of Variable Length Record). Adjust the Length of data element within each variable length record to accomplish this alignment.

[Guest.Visitor]

Oh, so it looks as though it is working, as reported by QDCRDEVD. However, I'll have to review the documentation; I didn't think this was how it used the IP address. When I enter an IP address, it returns the sign-on screen of my system. What is it doing, then, with the IP? I wanted to enter the IP address of another system and get the sign-on screen from that machine, so, just as if I were running TELNET to the destination machine from the original machine's command line. Is this possible? I guess I could sign on and then perform a TELNET...

[Guest.Visitor]

Sorry, but that is not the intent of the network address key. It is basically so that system users can determine what address is accessing the virtual terminal (interactive) job. The general idea is for a client to access a server job which then controls the virtual terminal session. The server job feeds the QTVOPNVT API the network address of the requesting client so that the system operator can then "see" what client is using the application/job. You need to call the API from the system where the application resides.