Retrieving a Display Session’s IP Address

Dumb Joke of the Month

My landlord called, said he wanted to discuss why my heating bills were so high. I said “Sure!  My door is always open.”

Retrieving a Display Session’s IP Address

This is a question that comes up quite frequently. It’s often useful for a program running on the IBM i to know the IP address that a user is connecting from. 

To put it another way: We know our users will be connecting via a 5250 telnet client such as IBM’s Access Client Solutions, how could we find out the IP address of the PC they are connecting from?  Often times this is useful to make a log of the IP address that initiated a transaction.  Or in some cases, it’s useful to connect back to their device over the network, for example, to access a shared drive, or access a custom network server that is running there.

IBM provides the IP address of a 5250 device through the Retrieve Device Description (QDCRDEVD) system API. This API is a program that IBM provides with the operating system that you can call as needed – but many people find all of its options and formats to be a little confusing.

If all you want to do is get the IP address, it’s easy once you know how.  For example:

PGM PARM(&DEV &IP)

 

   DCL VAR(&DEV)       TYPE(*CHAR) LEN(10)

   DCL VAR(&RCVVAR)    TYPE(*CHAR) LEN(1000)

   DCL VAR(&RCVVARLEN) TYPE(*CHAR) LEN(4)

   DCL VAR(&ERRCODE)   TYPE(*CHAR) LEN(8)   VALUE(X’00000000′)

   DCL VAR(&IP)        TYPE(*CHAR) LEN(15)

 

   CHGVAR VAR(%BIN(&RCVVARLEN)) VALUE(1000)

 

   CALL PGM(QDCRDEVD) PARM( &RCVVAR    +

                            &RCVVARLEN +

                            ‘DEVD0600’ +         

                            &DEV       +         

                            &ERRCODE   )

 

   CHGVAR VAR(&IP) VALUE(%SST(&RCVVAR 878 15))

 

 

ENDPGM

 

Since we know the IP address is always located at position 878 of the DEVD0600 format, almost everything can be hard-coded, so this program is short and sweet.

  • &RCVVAR – The variable to receive the output of the API
  • &RCVVARLEN – Length of the receiver variable, hard-coded to 1000 since our &RCVVAR is defined as CHAR(1000)
  • ‘DEVD0600’ – tells the API that we want display device information.
  • &DEV – name of the device to retrieve information about
  • &ERRCODE – Hard-coded to all hex zeroes, this tells the API to return errors as *ESCAPE (exception) messages instead of returning them in strings to our program.

Once the API call is over, the last line of the program substrings the IP address from position 878 of the receiver variable – it is always in the same spot when using the DEVD0600 format.

Now whenever you want the IP address of a device, you can call the above program (which I called ‘GETIP’ on my system)

 

PGM

   DCL VAR(&DEV) TYPE(*CHAR) LEN(10)

   DCL VAR(&IP)  TYPE(*CHAR) LEN(15)

 

   RTVJOBA JOB(&DEV)

 

   CALL PGM(GETIP) PARM(&DEV &IP)

 

   SNDUSRMSG  MSG(&IP) MSGTYPE(*INFO)

ENDPGM

In this case, it gets the current job name with RTVJOBA – the job name will match the device name if you are in an interactive job.  For example, if your device name is QPADEV0001, the job name will also be QPADEV0001, and therefore that will be passed to the GETIP program.   This is an easy way to return the address of the current job.

I have not yet coded my GETIP to work with IPv6.  If IPv6 were used to connect the display device, the above program would return the special value *IPV6.   It is certainly possibly to upgrade the code to handle this situation and to retrieve the IPv6 address instead (it is located elsewhere in the DEVD0600 receiver variable) but I will leave this as an exercise for the reader.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *