By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Have you ever wanted to know the IP address of a connected workstation? Well, the iSeries has an API that can get that for you. You may want to implement security schemes, add business rules, use different display files, etc. depending on the IP. By knowing all or even part of the IP address, you can control how your programs communicate with the device.
The "QDCRDEVD" API retrieves information about a device description. This is simple to use and will return a host of information, not just the IP address. Below is the typical RPG IV call to the "Retrieve Device Description" API.
DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++ D #PGMDS SDS D @PGMNM *PROC D @JOB 244 253 D @USER 254 263 D DEVDDS DS 1024 D IPADDR 877 891 CL0N01Factor1+++++++Opcode&amp;amp;amp;ExtFactor2+++++++Result++++++++Len++D+HiLoEq C** Call the API to get the IP address C* C CALL 'QDCRDEVD' C PARM DEVDDS C PARM DEVDLG 4 C PARM 'DEVD0600' DEVDFM 8 C PARM @JOB DEVDNM 10 C PARM DEVDER 256 C* C** Load the IP Address C* C MOVEL(P) IPADDR @ADDR
The "DEVDDS" data structure is the information returned from the API. This is also the first of the five parameters of the API. Depending on the format requested, the information and layout returned in the DEVDDS data structure will change. The second parameter is length of the data returned in the first parameter.
The next parameter is the format in which the information is returned. There are several formats to choose from, depending of the type of information you're looking for. The "DEVD0600" format I used above lists very detailed information. For a list of available formats, go to IBM's online library and search all books for "QDCRDEVD".
The fourth parameter is the device name, which is passed to the API for the information to be retrieved. The fifth parameter contains any error message ID's that may be returned. The message ID's can be found in Message file QSYS/QCPFMSG.
Give this API a try the next time you want the IP address.
About the author: John Kohan is a senior programmer analyst at CT Codeworks. He is also an adjunct instructor teaching AS/400 classes at his local state college.
- Identify the TCP addresses of telnet users:
One user was looking for the easiest way to identify the TCP addresses of his telnet users? Site expert Kenneth Graap offers a suggestion and provides a program to extract that information.
- The Best Web Links on Development: Tips, tutorials and more.
- Ask your programmer questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our programmer gurus are waiting to answer your technical questions.
- This tip is very useful in principle. However, as it stands it does not retrieve the IP address correctly and could corrupt memory and crash the program in which it is called.
1. The position of the IP address within the data structure is off by one. It should be 878 to 892, not 877 to 891. Position 877 is the last byte of the network protocol address. This illustrates a potential pitfall for RPG programmers when reading IBM's API manuals. In its layout of information returned from an API, IBM gives the offset and length for each field. Offsets start at zero, and are convenient for C programmers. However, a data structure in RPG starts at position 1. Therefore, the starting position for a given field is always 1 + the offset as shown in the manual.
2. The second parameter, DEVDLG, is a length, though this is disguised by its being declared as character. It is an INPUT parameter that tells the API how many bytes to return. It should be declared as binary or integer (9b 0 or 10i 0) and set to 892, in this case. It is important that this length is correctly specified. In this case, the data returned on format DEVD0600 of QDCRDEVD can be longer than the declared length of the data structure, 1024 bytes. (It contains a repeating block for auxiliary devices.) Because the value in DEVDLG (which the API will see as a binary field) is x'40404040', or over 10MB, serious memory corruption could occur if the API returns more data than 1024 bytes. Even if this were a fixed length format, it would still be important to explicitly tell the API how many bytes to return, in case IBM increases the length of the format in a future release.
3. A similar problem exists with the error parameter, DEVDER. In the standard API error format, the first 4 bytes is a binary field that tells the API how many bytes are provided for returning exception information. Again, if DEVDER is blank this field will be over 10 MB. If the API returns more than 256 bytes, memory corruption could occur, with unpredictable results. It's unlikely the exception information would be longer than 256 bytes, but why take the chance?
4. *PROC is not the program name, as the field name suggests, but that's irrelevant here. Nick Hobson
- In addition to previous feedback, there is an additional potential issue -- the device might not be a TCP/IP device, it might be an SNA device. In order to determine that it is a TCP/IP device, the Network protocol field at pos. 859 (offset 858) of the DS can be checked for the value x'02'. If the value is x'06', then the protocol is IPX. Since these are the only protocols involved in telnet, other values would indicate non-telnet devices and are commonly considered grouped into SNA passthru devices. The SNA Remote location name can be extracted from the DS in pos. 255-264 (offset beginning at 254 for 10 characters).. Thomas Liotta