Today this function is performed from within SAS (with reasonable success - some IP-addresses are not known to the z/OS resolver) using the SAS "pipe" engine and the USS "host" command, based on SMF 119 source-information references (the IP-address).
Scott Barry SBBTech LLC On Wed, 22 Jul 2020 18:23:38 +0000, Martin Packer <martin_pac...@uk.ibm.com> wrote: > >If it were me I’d probably extract the IP addresses, use another program to >look them up, then do a DFSORT / ICETOOL JOIN on the original report and >the looked up IP addresses / domains. (And take any ambiguity as inevitable >dirtiness in the data.) > >Cheers, Martin (NOT a DFSORT developer) > >Sent from my iPad > >> On 22 Jul 2020, at 19:02, Charles Mills <charl...@mcn.org> wrote: >> >> I don't know but it sounds to me like kind of an inappropriate function >to graft onto a sort program. Why not dollar to Euro conversion? Or meters >to feet? >> >> Keep in mind (as @Shmuel said) that one IP address could have multiple >"source" domains or URLs, and also that the mapping can change with no >notice. >> >> Equally interesting -- perhaps more so from a security point of view -- >is geo-location. Knowing that IP address xxx.xxx.xxx.xxx is in China or >Bulgaria. >> >> Charles >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Tim Hare >> Sent: Wednesday, July 22, 2020 9:58 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Possible new function for DFSORT? >> >> I don't think this function exists, and I'm thinking about writing up a >SHARE requirement for it (which I guess these days becomes an RFE but I'm a >member of SHARE so I think I'll go that way). I thought I'd ask whether >it would be used enough to justify going through that process. >> >> What I'm thinking about is a function (well, two) to take a binary IP >address and do DNS lookup, retrieving the host/domain name. At the shop >where I'm currently working, many logs don't do the lookup when logging, >to save some overhead. Yet, it's always nice, when creating a report >such as 'who is connecting to us the most', to be able to assign a name >rather than an IP address; if the lookup can be done _after_ the data is >summarized it would be a lot more efficient. Hence the thinking about >making this a function for SORT. >> >> I think this would involve two functions - one for IPV4 and one for IPV6. >We might also like two formats similar to DT1 and the like, for formatting >IPV4 and IPV6 binaries into strings. Although I think that can be managed >now by handling individual parts of the binary and interspersing separator >characters "manually" it would be much cleaner if it were handled like >date/time fields are. >> >> Do you think this capability would be used enough to make it an RFE? >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>Unless stated otherwise above: >IBM United Kingdom Limited - Registered in England and Wales with number >741598. >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
