Re: Getting the SMF time

[Shmuel Metz (Seymour J.)]

In <2349677958380831.wa.dlikensinfosecinc@listserv.ua.edu>, on
10/28/2013
   at 09:55 PM, Donald Likens  said:

>STCK time is based on micro seconds.

Well, microseconds in bit 51.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Skip Robinson]

Speaking of time: US Daylight Saving Time ends this Sunday November 3. We 
all get to relive one hour. Good for sleeping, but problematic for some 
software. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Elardus Engelbrecht 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   10/29/2013 04:23 AM
Subject:Re: Getting the SMF time
Sent by:IBM Mainframe Discussion List 



Barry Merrill  wrote:

>Some of us find SAS's
> INPUT @3 SMFTIME SMFSTAMP8.;
> FORMAT SMFTIME DATETIME21.2;
> PUT SMFTIME=;

>easier and it prints
> 27OCT2013:13:14:15.99

Indeed, it is very easy and there are many ways to skin this cat with the 
name SMFTIME. :-)
Or if you're a hunter, aim for the head, neck or heart. Same deadly 
results. ;-)

Or for those who are too poor or cheapskate to use SAS, you can try 
ICETOOL like this fun sample, SMF type 89:

//SMF89EXEC  PGM=ICETOOL 
//TOOLMSG  DD  SYSOUT=* 
//DFSMSG   DD  SYSOUT=* 
//VLSHCNTL DD  * 
 OPTION COPY,VLSHRT 
 INCLUDE COND=(6,1,BI,EQ,X'59') 
/* 
//RAWSMF   DD  DISP=SHR,DSN=
//SORTSMF   DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(50,50,0))
//VREPTDD  SYSOUT=* 
//TOOLIN   DD  *  CONTROL STATEMENTS 
  SORT FROM(RAWSMF) TO(SORTSMF) USING(VLSH) 
  DISPLAY FROM(SORTSMF) LIST(VREPT) - 
 HEADER('SMFTYPE')  ON(6,1,BI) - 
 HEADER('DATE')ON(11,4,DT1,E'/99/99') - 
 HEADER('TIME')ON(7,4,TM1,E'99:99:99') - 
 HEADER('SYSTEM')  ON(15,4,CH) 

Credits to Frank Yaeger for this one! ;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Elardus Engelbrecht]

Barry Merrill  wrote:

>Some of us find SAS's
> INPUT @3 SMFTIME SMFSTAMP8.;
> FORMAT SMFTIME DATETIME21.2;
> PUT SMFTIME=;

>easier and it prints
> 27OCT2013:13:14:15.99

Indeed, it is very easy and there are many ways to skin this cat with the name 
SMFTIME. :-)
Or if you're a hunter, aim for the head, neck or heart. Same deadly results. ;-)

Or for those who are too poor or cheapskate to use SAS, you can try ICETOOL 
like this fun sample, SMF type 89:

//SMF89EXEC  PGM=ICETOOL 
//TOOLMSG  DD  SYSOUT=*  
//DFSMSG   DD  SYSOUT=*  
//VLSHCNTL DD  * 
 OPTION COPY,VLSHRT  
 INCLUDE COND=(6,1,BI,EQ,X'59')  
/*   
//RAWSMF   DD  DISP=SHR,DSN=
//SORTSMF   DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(50,50,0))
//VREPTDD  SYSOUT=*  
//TOOLIN   DD  *  CONTROL STATEMENTS 
  SORT FROM(RAWSMF) TO(SORTSMF) USING(VLSH)  
  DISPLAY FROM(SORTSMF) LIST(VREPT) -
 HEADER('SMFTYPE')  ON(6,1,BI) -  
 HEADER('DATE')ON(11,4,DT1,E'/99/99') -  
 HEADER('TIME')ON(7,4,TM1,E'99:99:99') - 
 HEADER('SYSTEM')  ON(15,4,CH)   

Credits to Frank Yaeger for this one! ;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Barry Merrill]

Some of us find SAS's 
 INPUT @3 SMFTIME SMFSTAMP8.; 
 FORMAT SMFTIME DATETIME21.2;
 PUT SMFTIME=;

easier and it prints  

 27OCT2013:13:14:15.99 

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, October 29, 2013 2:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting the SMF time

Donald Likens wrote:

>I figured out the problem... The SMFTIME is obtained by TIME BIN which returns 
>BIN returns the time of day as an unsigned 32-bit binary number with the 
>low-order bit equivalent to 0.01 second. The second word of the time value 
>returned is zero. STCK time is based on micro seconds.

Yes. SMFTIME is 2 full words. As documented it is 'Time since midnight, 
in hundredths of a second'.

Granted, I have not time to play around with TIME macro on SMF data/time, but 
only used to get local time or Greenwich time.


>To have the work close I would need to multiply the SMFTIME by 100 (if I 
>figured this correctly)... I choose to handle my problem a different way.

Why 'multiply the SMFTIME by 100'? On what is that value based? I must 
missing something obvious.

What I do (I believe there are better and elegant handling of those SMF date 
and times in Assembler or in LE languages to get your values. I think freebies 
on CBTTAPE like DAF have source samples for that too.): 

I take the value, SMF30TME for example, feed it into CONVTOD TIMETYPE=BIN, then 
to STCKCONV TIMETYPE=DEC, divide it by 36 to get my hours. Divide remainder 
by 6000 to get my minutes. Divide remainder by 100 to get my seconds and last 
remainder. Then I do my converts, force sign and unpack these values. Some 
MOVes later I have all my values placed in a nice string pre-filled in with 
separators ready for display on reports.

I do similar work for dates to extract year, month and day from my SMF records 
which are in Julian format and strange century bit (somewhat weird. :-D ).

Not perfect, but it is working because I need to compare those date/times with 
parameters given for my reports. ;-)

I can e-mail to you the partial source (in Assembler), if you wish. I used that 
to write out audit reports directly from SMF records.

Groete / Greetings
Elardus Engelbrecht

--
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

Re: Getting the SMF time

[Elardus Engelbrecht]

Donald Likens wrote:

>I figured out the problem... The SMFTIME is obtained by TIME BIN which returns 
>BIN returns the time of day as an unsigned 32-bit binary number with the 
>low-order bit equivalent to 0.01 second. The second word of the time value 
>returned is zero. STCK time is based on micro seconds.

Yes. SMFTIME is 2 full words. As documented it is 'Time since midnight, 
in hundredths of a second'.

Granted, I have not time to play around with TIME macro on SMF data/time, but 
only used to get local time or Greenwich time.


>To have the work close I would need to multiply the SMFTIME by 100 (if I 
>figured this correctly)... I choose to handle my problem a different way.

Why 'multiply the SMFTIME by 100'? On what is that value based? I must 
missing something obvious.

What I do (I believe there are better and elegant handling of those SMF date 
and times in Assembler or in LE languages to get your values. I think freebies 
on CBTTAPE like DAF have source samples for that too.): 

I take the value, SMF30TME for example, feed it into CONVTOD TIMETYPE=BIN, then 
to STCKCONV TIMETYPE=DEC, divide it by 36 to get my hours. Divide remainder 
by 6000 to get my minutes. Divide remainder by 100 to get my seconds and last 
remainder. Then I do my converts, force sign and unpack these values. Some 
MOVes later I have all my values placed in a nice string pre-filled in with 
separators ready for display on reports.

I do similar work for dates to extract year, month and day from my SMF records 
which are in Julian format and strange century bit (somewhat weird. :-D ).

Not perfect, but it is working because I need to compare those date/times with 
parameters given for my reports. ;-)

I can e-mail to you the partial source (in Assembler), if you wish. I used that 
to write out audit reports directly from SMF records.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Donald Likens]

I figured out the problem... The SMFTIME is obtained by TIME BIN which returns 
BIN returns the time of day as an unsigned 32-bit binary number with the 
low-order bit equivalent to 0.01 second. The second word of the time value
returned is zero. STCK time is based on micro seconds.

To have the work close I would need to multiply the SMFTIME by 100 (if I 
figured this correctly)... I choose to handle my problem a different way.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Bill Godfrey]

On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote:

>I already convert the SMF time into human time by using arithmetic but I am 
>having a problem with the calculation and I am attempting to use the ASM 
>macros to convert the time. Here is what I am doing:
>
>*  CREATE TODDATE 
> MVC   SMFDATE,SMF2DTE
> MVI   SMFDATE,X'20'  
> L R2,SMFDATE  R2  X'20YYDDDS'
> SRL   R2,4R2  X'020YYDDD'
> STR2,CVDATE   CVDATE  XL4 X'020YYDDD'
> MVC   CVZERO,ZERO
> CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD
>*  SET TIME   
> L R2,TODTIME 
> A R2,SMF2TME 
> STR2,TODTIME 

If you use DATETYPE=YYDDD instead, you can replace the 5 instructions from MVC 
to ST with this:
  MVC   CVTD+8(4),SMF2DTE

If you use TIMETYPE=BIN and add this instruction before CONVTOD:
  MVC   CVTD(4),SMF2TME
then you can eliminate the L,A, and ST instructions after CONVTOD.
Also, you might get the result that you are expecting.

Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Mike Schwab]

On Fri, Oct 25, 2013 at 8:50 AM, Donald Likens  wrote:

>  CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD

> This returns what looks to me to be a good TODCLOCK
> TODCLOCK
>+0  CC208E64 F236F8F4

http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.ieaa900%2Fiea3a9_Description14.htm

>
> Now I do a
>  STCKCONV STCKVAL=TODCLOCK,CONVVAL=TMECVTD,DATETYPE=MMDD,  +
>TIMETYPE=DEC
> It returns:
>
> TMECVTD
>+0   0867 10182013 
>
> The time is not correct (the date is). Any ideas on what I am doing wrong? By 
> my calculations the time should be 14:52:00.16.
>
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieaa900/iea3a9_Description14.htm
TIMETYPE=DEC returns x'HHMMSSss' so  plus 00.000867 seconds.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Paul Gilmartin]

On Fri, 25 Oct 2013 10:01:20 -0500, John McKown wrote:

>If I were in charge (no chance), I would go with exactly TWO different
>... While I'm at it, the default TZ in LE and UNIX, if not
>specifically set, should also be assumed to be the equivalent of what the
>offset is in the CVT.
> 
How would you deal with the matter that (in winter) Colorado and
Arizona have identical values of CVTLDTO in the CVT, but Colorado
has TZ=MST7MDT and Arizona has TZ=MST7?

Rather, since TZ has the greater functionality, I'd advocate the
opposite convention: if CVTLDTO is set to some reserved value
(e.g. 8X'FF'), TZ as set in the z/OS UNIX profiles should be used
for conversion to local time.  How about making TZ a special
JCL symbol so users in geographically diverse locations could
get output timestamped according to their local conventions.

All system logs should be timestamped in UTC.

ISPF PDS member timestamps should be in UTC.

Leap seconds?  POSIX screwed up unforgivably and irreparably
by writing an internally contradictory specification.

Thus:

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html

The Open Group Base Specifications Issue 7
IEEE Std 1003.1, 2013 Edition
Copyright © 2001-2013 The IEEE and The Open Group

..., it is inappropriate to require that a time represented as seconds
since the Epoch precisely represent the number of seconds between
the referenced time and the Epoch.

???

MVS made a halfhearted attempt to do better.  How would your
proposal handle CVTLSO?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[John McKown]

If I were in charge (no chance), I would go with exactly TWO different
versions of a time stamp on z/OS. A binary one, which "just happens" to be
identical to the output of the STCKE instruction (16 bytes, 128 bits). And
a character one which is the full ISO8601 format (
mmddThhmmss.s+hh:mm ). And some system function which translates
between the two. I don't really know if 5 digits after the decimal point is
the "best" precision. And the + is a + or - and is based on the offset kept
in the CVT. While I'm at it, the default TZ in LE and UNIX, if not
specifically set, should also be assumed to be the equivalent of what the
offset is in the CVT.


On Fri, Oct 25, 2013 at 9:16 AM, Paul Gilmartin wrote:

> On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote:
> >
> >
> >TMECVTD
> >   +0   0867 10182013 
> >
> >The time is not correct (the date is). Any ideas on what I am doing
> wrong? By my calculations the time should be 14:52:00.16.
> >
> Since IBM refuses to document the behavior of STCKCONV (they
> say it should be "common knowledge" in response to my RCF),
> it's pretty hard to say any result is right or wrong.
>
> And it has been discussed here that among various SMF record
> types there are radically different conventions for representation
> of the timestamp.  Some argue that this is proper given radically
> different requirements for range, precision, and API among those
> various various record types.  I'm unmoved by the argument.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Getting the SMF time

[Paul Gilmartin]

On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote:
>
>  
>TMECVTD   
>   +0   0867 10182013 
>
>The time is not correct (the date is). Any ideas on what I am doing wrong? By 
>my calculations the time should be 14:52:00.16. 
> 
Since IBM refuses to document the behavior of STCKCONV (they
say it should be "common knowledge" in response to my RCF),
it's pretty hard to say any result is right or wrong.

And it has been discussed here that among various SMF record
types there are radically different conventions for representation
of the timestamp.  Some argue that this is proper given radically
different requirements for range, precision, and API among those
various various record types.  I'm unmoved by the argument.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Getting the SMF time

[Donald Likens]

I already convert the SMF time into human time by using arithmetic but I am 
having a problem with the calculation and I am attempting to use the ASM macros 
to convert the time. Here is what I am doing:

*  CREATE TODDATE 
 MVC   SMFDATE,SMF2DTE
 MVI   SMFDATE,X'20'  
 L R2,SMFDATE  R2  X'20YYDDDS'
 SRL   R2,4R2  X'020YYDDD'
 STR2,CVDATE   CVDATE  XL4 X'020YYDDD'
 MVC   CVZERO,ZERO
 CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD
*  SET TIME   
 L R2,TODTIME 
 A R2,SMF2TME 
 STR2,TODTIME 
This returns what looks to me to be a good TODCLOCK
TODCLOCK 
   +0  CC208E64 F236F8F4

Now I do a 
 STCKCONV STCKVAL=TODCLOCK,CONVVAL=TMECVTD,DATETYPE=MMDD,  +
   TIMETYPE=DEC 
It returns:
  
TMECVTD   
   +0   0867 10182013 

The time is not correct (the date is). Any ideas on what I am doing wrong? By 
my calculations the time should be 14:52:00.16. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN