SMF Type 119 Records not being written

ts01spd · Post by **ts01spd** » Wed Jan 05, 2011 6:36 pm

Good Afternoon,

I believe FDC is currently working on obtaining a support contract but I've already been looking at and testing Co:Z SFTP (on a TECH only LPAR). The only issue I've seen is I can't seem to get the Type 119 records to be written.

I see Type 119 Records from FTP transmissions so I know they're allowed to be written.
I previously saw RACF messages indicating my USERID did not have READ access to BPX.SMF. I had this access granted and no longer see those messages so that looks good as well.

It looks like the records should be written but ... I updated my IEUF83 exit to display all record types and I see no SMF records of any type being written when I PUT an MVS DSN to the Mainframe using Co:Z SFTP.

I've reviewed the installation and user's guide but I don't see any additional that should be coded. Any suggestions?

Steve Dormady 303-967-6326

ts01spd · Post by **ts01spd** » Thu Jan 06, 2011 3:10 pm

We are running an older Ported Tools (sshd version OpenSSH_3.8.1p1), perhaps that is causing some impact? We are in planning to upgrade to the latest.

Post by **dovetail** » Thu Jan 06, 2011 4:54 pm

To debug this with the Co:Z sftp-server, sign in from a remote sftp client and then enable tracing of the SMF component:

sftp> ls /+loglevel=ZosSmf119Record=F

then do some put or get transfer and look at the user's sftp log file:

sftp> get /+error.log

You should see a hex dump of the Smf Record, and a trace output like this:

Code: Select all

ZosSmf119Record[F]: -> writeRecord()
ZosSmf119Record[F]: hexdump of smf119header (389 bytes):
ZosSmf119Record[F]:  >01850000 5E77004F 60850111 006FE2F0< .e..;..|-e...?S0 00000000 19912DE8
ZosSmf119Record[F]:  >E6F10000 00000046 00060000 0000004C< W1.............< 00000010 19912DF8
ZosSmf119Record[F]:  >00400001 0000008C 00B80001 00000144< . .............. 00000020 19912E08
ZosSmf119Record[F]:  >00040001 00000148 00170001 0000015F< ...............^ 00000030 19912E18
ZosSmf119Record[F]:  >00000001 0000015F 00260001 E2F0E6F1< .......^....S0W1 00000040 19912E28
ZosSmf119Record[F]:  >40404040 E2E5E2C3 D7D3C5E7 E3C3D7C9<     SVSCPLEXTCPI 00000050 19912E38
ZosSmf119Record[F]:  >D7404040 F0F1F0F8 F0F04040 E2C6E3D7< P   010800  SFTP 00000060 19912E48
ZosSmf119Record[F]:  >E2404040 D2C9D9D2 F6404040 D2C9D9D2< S   KIRK6   KIRK 00000070 19912E58
ZosSmf119Record[F]:  >40404040 00000025 08000000 04000000<     ............ 00000080 19912E68
ZosSmf119Record[F]:  >D9C5E3D9 E2C5D840 00000000 00000000< RETRSEQ ........ 00000090 19912E78
ZosSmf119Record[F]:  >0000FFFF 47559E86 00000000 00000000< .......f........ 000000A0 19912E88
ZosSmf119Record[F]:  >0000FFFF C05621A6 A97D0016 00000000< ....{..wz'...... 000000B0 19912E98
ZosSmf119Record[F]:  >00000000 0000FFFF 47559E86 00000000< ...........f.... 000000C0 19912EA8
ZosSmf119Record[F]:  >00000000 0000FFFF C05621A6 A97D0016< ........{..wz'.. 000000D0 19912EB8
ZosSmf119Record[F]:  >D2C9D9D2 40404040 C9E2C6C8 007055F8< KIRK    ISFH...8 000000E0 19912EC8
ZosSmf119Record[F]:  >0111006F 00705605 0111006F 0000000D< ...?.......?.... 000000F0 19912ED8
ZosSmf119Record[F]:  >00000000 000001F1 F2F5F040 40404040< .......1250      00000100 19912EE8
ZosSmf119Record[F]:  >40404040 40404040 40404040 40404040<                  00000110 19912EF8
ZosSmf119Record[F]:  >40404040 431F1000 00000000 00000000<     ............ 00000120 19912F08
ZosSmf119Record[F]:  >00000000 D2C9D9D2 F6F5F1F6 F8F64040< ....KIRK651686   00000130 19912F18
ZosSmf119Record[F]:  >40404000 E2F0E6F1 61E2F0E6 F161A394<    .S0W1/S0W1/tm 00000140 19912F28
ZosSmf119Record[F]:  >97619289 99924BA3 85A2A34B 96A4A3E3< p/kirk.test.outT 00000150 19912F38
ZosSmf119Record[F]:  >D7D7D740 40404040 40404040 40404040< PPP              00000160 19912F48
ZosSmf119Record[F]:  >40404040 40404040 40404040 40404000<                . 00000170 19912F58
ZosSmf119Record[F]:  >00000000 00<                         .....            00000180 19912F68
ZosSmf119Record[F]: -> writeDgRecord()
ZosSmf119Record[D]: Unable to send SMF 119 record to monitor socket "/var/log/cozsftp.smf.sock" - EDC5129I No such file or directory. (err
no2=0x0594003D)
ZosSmf119Record[F]: <- writeDgRecord(false)
ZosSmf119Record[F]: <- writeRecord(true)

In the last line, writeRecord(true) indicates that we got a 0 return back from "__smf_record()". If we didn't get a 0 return code, there should be an additional log message that describes the error. Note that the message above in writeDgRecord() is OK; it indicates that the Unix domain datagram socket facility is not active.

If this looks good (like above), and you are still not seeing the SMF record recorded in your system SMF dataset, then double-check to see if you have any SMF exits that are filtering out the record. If you have the ability in a sandbox LPAR to disable your SMF exits, try that to see if recording works.

ts01spd · Post by **ts01spd** » Fri Jan 07, 2011 1:45 pm

Morning,

One of my MVS guys replied with;
"The IEFU83 exit point only gets control if the caller uses the SVC version of the macro (BRANCH=NO). For the branch version of the macro, we need to set our module up at the IEFU84 exit point. And I suppose the IEFU85 exit point if the caller uses mode=xmem…

The other question is whether the caller specifies the SUBSYS= parameter. If this is the case then that subsystem has to be specified in the smf parmlib member with the exits specified for that subsystem.

Could you comment if Co:Z SFTP uses the SVC or BRANCH version and if SUBSYS= is specified?

ts01spd · Post by **ts01spd** » Fri Jan 07, 2011 2:00 pm

Ah ha, That was it. I activated the same exit for IEFU84 and I see my messages. Sweet. Thanks again for your consideration of my question.

Post by **dovetail** » Fri Jan 07, 2011 2:09 pm

I'm not sure how to answer your question re: SVC or BRANCH entry. We use the IBM __smf_record() C-library interface. It seems that this uses BRANCH entry, since fixing your IEFU84 exit solved the problem.