Co:Z SFTP 1.2.0 - SMF119 / resolver issue?

mmayne · Post by **mmayne** » Thu Jan 15, 2009 11:33 am

Just started yesterday using Co:Z SFTP from the Co:Z 1.2.0 distribution. Getting the following in the STDERR sysout:

ZosSmf119Record: getaddrinfo failed: EDC5000I No error occurred. (errno2=0x5B570103) for: hhsyslog:22

Put in a SYSTCPT DD SYSOUT=* to get a resolver trace - last call (#2) at the bottom:

GetAddrInfo Started: 2009/01/15 09:26:20.059432
GetAddrinfo Invoked with following inputs:
Host Name: hhsyslog
Service Name: 22
Hints parameter supplied with settings:
ai_family = 19, ai_flags = 0x0000001C
ai_protocol = 0, ai_socktype = 0
GetAddrInfo Failed: RetVal = -1, RC = 1, Reason = 0x78AE1006
GetAddrInfo Ended: 2009/01/15 09:26:20.059561

Trace info (from loglevel=T):

ZosSmf119Record[F]: -> initialize(HBOC.PROD.KPA02BC.I837.FRI)
ZosSmf119Record[F]: -> initHeader(reclen=376 subtype=3)
ZosSmf119Record[F]: <- initHeader()
ZosSmf119Record[F]: -> initIdentSection()
ZosSmf119Record[F]: -> getCurrentStackName()
ZosSmf119Record[F]: <- getCurrentStackName(TCPIP )
ZosSmf119Record[F]: <- initIdentSection()
ZosSmf119Record[F]: -> initFtpClientSection()
ZosSmf119Record: getaddrinfo failed: EDC5000I No error occurred. (errno2=0x5B570103) for: hhsyslog:22
ZosSmf119Record[F]: <- initFtpClientSection()
ZosSmf119Record[F]: -> initServerSecuritySection()
ZosSmf119Record[F]: <- initServerSecuritySection()
ZosSmf119Record[F]: <- initialize()

I've tried to find the meaning of the errno2 value (without success).

Looking at the resolver output, examining the ai_flags (1C), we have AI_NUMERICHOST && AI_NUMERICSERV && AI_V4MAPPED. If I'm reading the manual correctly, shouldn't we be passing the IP address of hhsyslog, instead of the name? That's the only clue I could come up with, however bogus or not. Anybody got a clue stick?

Thanks.
-Mike

Post by **dovetail** » Thu Jan 15, 2009 12:13 pm

Mike,

Thank you for reporting this problem. Your analysis is dead-on. We have a bug in sftp client so that the AI_NUMERICHOST is being turned on in cases where it shouldn't.

The good news is that this bug only affects the data that is placed in the SMF119 record (you won't get the right server IP address in the SMF record), and then only if you actually have SMF recording for 119 records enabled.

We will fix it in the next maintenance release.

Thanks,
Kirk Wolf

mmayne · Post by **mmayne** » Thu Jan 15, 2009 12:22 pm

Kirk, even a blind squirrel can find an acorn occasionally

.

Is there any way to disable SMF119 record generation? We have a RACF facility class profile in place for BPX.SMF, and the only way to stop getting ICH408I messages is to either make the profile a UACC of READ, or add all of the users and / or groups to the access list of the profile. This is assuming, of course, that we wouldn't want to make the caller of the SMF write authorized...

Thanks.
-Mike

Post by **dovetail** » Thu Jan 15, 2009 12:53 pm

The as written will try once to write an SMF record and if it fails due to either authorization (doesn't have read access to BPX.SMF) or if SMF recording is not enabled for 119 records, then it won't try again.

I'm not sure about ICH408I - is this really the message that you are getting? The docs for this seems to indicate that it is about something else. Can you post an example of the messages that you are getting?

mmayne · Post by **mmayne** » Thu Jan 15, 2009 1:01 pm

---- WEDNESDAY, 14 JAN 2009 ----
IRR010I USERID MMAYNE IS ASSIGNED TO THIS JOB.
ICH70001I MMAYNE LAST ACCESS AT 14:57:55 ON WEDNESDAY, JANUARY 14, 2009
$HASP373 SFTPTST1 STARTED - INIT 1 - CLASS Y - SYS HHSP
ICH408I USER(MMAYNE ) GROUP(HHSYSMGT) NAME(MICHAEL R. MAYNE ) 265
BPX.SMF CL(FACILITY)
INSUFFICIENT ACCESS AUTHORITY
ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
- --TIMINGS (MINS.)-- ----PAGING COUNTS---
-JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE SWAP VIO SWAPS STEPNO
-SFTPTST1 COZSFTP SPAWN 00 3494 .00 .00 .52 3729 0 0 0 0 0 1
-SFTPTST1 ENDED. NAME-Systems Management TOTAL CPU TIME= .00 TOTAL ELAPSED TIME= .52
$HASP395 SFTPTST1 ENDED

You might not see it if you don't have any profile defined for BPX.SMF...

-Mike

Post by **dovetail** » Thu Jan 15, 2009 1:07 pm

I understand.... I guess there is no way in RACF to supress these "audit" messages"?

Otherwise, I think we will look in to adding an environment variable that can be used to disable it. I can see how it could get annoying - although we already disable repeated attempts from the same job.

Post by **dovetail** » Fri Jan 23, 2009 4:35 pm

We've added a feature that can be used to disable SMF recording.

See: http://dovetail.com/forum/viewtopic.php?t=748